VIEWS: 3 PAGES: 24 POSTED ON: 12/30/2011
Specific Name of Level of Comment Section # Person Severity Submitting (high- (optional) serious or low - grammar/ spelling) 3 CAL high Requested Procedure is defined as resulting in one or more reports. Radiology TF and Departmental Whitepaper have a Requested Procedure resulting in a single Report. 3 CAL high Technical Committee Discussion Due to the way Cath is scheduled, the PIR Profile has been integrated into to the Scheduled Workflow. The presentation provides one flow with all of the cases. 3 GE_CP mid In the following paragraph: Although the major cases for cath workflow are described in the following subsections, it is beneficial to also see the corresponding workflows in radiology. Rad TF-1: 3.3 has a description of the “normal” scheduled workflow when all three levels of control in the data model are fully utilized for known patients, and Rad TF-1: 4.3 and 4.4 describes workflows when the patient is unknown and/or the ordering and scheduling process is short-circuited (e.g., in the emergency case). It seemed to be implied that the three levels are not”used” in special cases. This is wrong. They are always present and used, however, not to their full extend. 3.2 Teri Sippel high OK, remind me, why is Patient Based Worklist Query "O" for optional? Throughout the use cases we talk about a patient wrist band/scanner. Why not require it for all modalities? 3.2 CAL mid In the Rad TF this section talked about additional options available within Scheduled Workflow. In Cardio some of the “OPTIONAL” options are required, bu there are some 3.2 CAL high Technical Committee Discussion: Is it reasonable for optional scheduled workflow items to become required? It is certainly true that things work better if everything is automated, but is the bar being set too high? 3.2 agfa-pas low Table 3.2-1: What does it mean for an "option" to be "required"? The 'Optionality' column in table 3.2-1 makes this "options" table inconsistent with the options tables in the other frameworks. (Same comment applies to table 4.2-1 in section 4.2). 3.3 CAL high Paragraph labeled: Modality Procedure Step In Progress and Update Schedule:MPPS In Progress is behaving completely different then the Radiology MPPS In Progress. Radiology MPPS In Progress would treat the procedure as “Unscheduled”.The process for updating the rest of the schedule would then be out of scope for IHE.I don’t even think the current DICOM MPPS will allow the MPPS N-Create and resulting N-Set parameters to work as specified. 3.3 CAL high Paragraph labeled Query Modality Worklist: Why is it a requirement that a Broad Query be done in order to make the process work? Either query may work, it depends on the way the Systems work. 3.3 CAL mid Paragraph labeled Perform Acquisition: Re-word the last sentence in the paragraph “The Image Manager/Archive must support all these object types beyond just images” to 3.3 CAL mid Paragraph labeled Modality Procedure Step Complete: The text in this paragraph is not sufficient to explain how the MPPS Complete is used. Additional information is required along with how the DISCONTINUED status is used. Please clarify the statement “It is up to the DSS/OF to determine when the modality resources in the room are available for another procedure”. 3.3 CAL mid Paragraph labeled Storage Commitment:The requirement stated in this paragraph is no different from the RAD TF Storage Commitment. 3.3 Camtronics In the bullet point starting with “Modality Procedure Step In Progress…”: A “modality ID” is referred to. 3.3 GE_CP low The use of the word attribute is surprising in Volume 1 in : “so there needs to be a way for all of the participating modalities to coordinate and to share attributes.” 3.3 GE_CP The title of this section should be Cath Scheduled Workflow. There are many additions to the radiology scheduled workflow, so it needs to be just part of Cath Workflow. 3.3 TDO high Paragraph labeled: Modality Procedure Step In Progress and Update Schedule: We talk about "starting" a procedure - but there is no discussion on how the DSS would know when not to provide the current procedure to a modality using a broad-query.We have to avoid a broad-query resulting in the incorrect patient. 3.3 agfa-sg high The "Start Procedure" activity that is performed by the Order Filler does not seem to make sense in these workflow scenarios. Who benefits from this activity? The information is not propogated to any other systems. It appears to be an activity that is only used by the Order Filler, so I don't know that it belongs in the IHE Framework. (In addition, this is the only status event, e.g. there is no "End Procedure"). 3.3 smm Under Create Order: The Order Placer is the enterprise repository for all patient orders. 3.3 Teri Sippel high 3rd para under IHE Context which begins with "Note that the transactions for Modality Image…" : This sentence is actually quite important but is easily missed. 3.3 Teri Sippel high The MPPS transactions for the "N" modalities in all of the following use case diagrams are not shown but nowhere does it say that these transactions are implied. 3.3 CAL mid Discussion on grouping of PPS Mgr should be re-worded. First it is stated that it is presumed grouped with the IM, and then the text goes on to talk about alternative groupings. 3.3 Teri Sippel high In echo, PPS Exception Mgr is optional Rad-TF 2: 4.7. I think it should be at least optional for cath as well, if not required. 3.3 Teri Sippel low case # does not appear in Figure titles as it does in Echo use cases 3.3 Camtronics IHE-Rad SWF shows Transactions 11 and 42 between the DSS/OF and the IM/IA. 3.3 Camtronics IHE-Rad SWF has Transactions 11 and 42 in the DSS/OF actor and Transactions 11 and 42 in the IM/IA actor. 3.3 Camtronics IHE-Rad PIR has Transaction 12 in the IM/IA actor. 3.3 Teri Sippel low transactions in figures are lower case, but transactions in text are upper case (eg, CARD-1) 3.3 Rick Bennett mid Many of these transaction diagrams have image manager and image archive as essentially a single entity. I'd prefer to see them separated, with the image manager actor having the transactions with image display and acquisition modality. 3.3 Teri Sippel high Image Manager/Archive is missing a transaction 3.4 GE_CP low This table is confusing because it achieves two purposes. First to select options from CLW for applicability into CARD-SWF. Second it list which the option that an implementor of CLW may chose to support. This needs to be presented in a two step process. 3.4 CAL low Differences between Rad and Cath are shown in color. Not everyone has access to color printers 3.4 GE_CP mid The definition of start procedure is very unclear 3.4 GE_CP In the bullet modality procedure step started, the sentence: “If the DSS/OF has not started the procedure, upon receipt of first MPPS In Progress for the Cath Lab, which includes the patient ID/name and the modality ID” Uses the term Modality ID. Why introducing a new term is it AE Title or Station ID ? 3.4 GE_CP In Query Modality Worklist bullet, why these wishy washy terms of may, would, Is there one and only one in that case or not ? 3.1 – Fig GE_CP In the Storage commitment bullet, why 3.1-1 use only “must” and not “shall” in relationship to the support of mobile devices. 3.1 – Tab Teri Sippel mid Table of use cases is misleading… 3.1-1 clinical folks will think we are dreaming. 3.1 – Tab Teri Sippel mid what does the Note apply to? 3.1-1 3.1-1 CAL mid IHE Context: Case2 is currently supported by RAD Scheduled Workflow 3.1-1 Fig agfa-pas low IHE Context: Might be useful to reference the cases from the Rad-SWF and Rad-PIR profiles which are covered by this case 3.1-1 Tab Teri Sippel high 2nd para in IHE Context: should it say 3.1-1 something about using a 'generic' procedure code (I know it is covered in Vol 2). 3.2.1 Tab CAL high C3 -Regarding the Auto-create Procedure How does the DSS/OF know when an MPPS N-Create (unscheduled procedure) is the start of a new case? 3.3 Fig 3.3-TDO grammar Note - the differences between the 1 radio and cardio TF should be bulleted for effect 3.3 p26 Camtronics In the bullet point starting with “Using the information from the MPPS transaction…”: A “modality station name” is referred to. 3.3 p27 TDO grammar the explanation of the working of the MPs in progress is simikar to the discussion in 3.3 above 3.3 p27 agfa-sg mid When the Order Filler auto-creates the procedure (upon receiving MPPS In Progress), the other modalities will the other modalities use the study_instance_uid that was supplied by the first modality? I would assume that would be the case, and the order filler would not generate a new one - otherwise the images on the archive would have a different study than the order filler. If this is the case, it should be clearly described in this use case. If it isn't, then details about how the images get synced up with the order filler should be described. 3.3 p27 CAL high C4 – Emergency Patient with Procedure Ordered The workflow defined here is normal except for the fact that PIR is required. 3.4 table agfa-sg mid I think that the Order Placer should get 3.4-1 the order status update sent to it from the filler order at the end of this use case (Patient Registered at DSS/OF and Procedure Ordered). I don't believe that the Filler Order Management - New transaction supports order status. However, the order status can be sent in the Order Managment Order Status Update transaction. 3.4 table Teri Sippel high after fig 3.4-5 bullet 4 - it is kind of 3.4-1 wimpy. Sounds like a recommendation, not a requiremetn. 3.4.1 agfa-sg mid I think that the Order Placer should get the order status update sent to it from the filler order at the end of this use case (Patient Not Registered). I don't believe that the Filler Order Management - New transaction supports order status. However, the order status can be sent in the Order Managment Order Status Update transaction. 3.4.2 agfa-pas mid The first note under the IHE Context section discusses the possibility of a time lag between MPPS in-progress and availability of SPSs in the MWL. How frequent is this case? If frequent enough, not addressing it in this profile will limit the usefulness of the profile. 3.4.2 CAL mid C6 – Patient Update during Procedure. This is covered by PIR 3.4.3 Teri Sippel low clinical scenario' should be 'clinical context' 3.4.3 Teri Sippel high assumption of what is in a Requested Procedure is too naïve. 3.4.3 CAL high C7 – Change Room During ProcedureWhat information goes into the IOD headers, etc. Append is normally done on the same Modality. If the room change is to a different modality then what? (Same procedure, but different equipment) 3.4.3 agfa-sg high It appears as though this use case is asking modalities to pick procedures from a worklist, even if the procedure has not been scheduled for that particular modality. This seems to be something new that is being asked of the modalities. I think that in Year 2, the intent is to have the entire scheduling ownership in the order filler. I don't see any reason in Year 1 to have modalities add support for finding procedures that are scheduled on a different modality. I would suggest enforcing that the filler updates the scheduling information before the next modality performs a worklist query. 3.4.3 agfa-sg mid I don't understand why modality 1 and modality 2 can both be responsible for sending the MPPS Discontinued message. I think it would be more beneficial to just select the original modality or the target modality. 3.4.3 / Rick Bennett low I'd prefer to have a reminder in the 3.4.5 legend of the figure as to what Case is being displayed. In this figure, simply say "Figure 3.4-5. C-5. Patient not registered" 3.4.3, GE-HS We especially need clarification Page 33 on: 3.4.4 GE-HS We need either a new section in this appendix, or another appendix, that discusses the use of various procedure and protocol codes for a diagnostic exam that evolves into an interventional exam. 3.4.4 Camtronics In Cases automatically created SPS be closed? If automatically created SPS be closed? If automatically created SPS’s are available for a long period of time, it seems like a procedure performed a day or so later (unrelated to the original order) may accidentally get associated with the original procedure. 3.4.5 KOD high Introducing Clinical Context vs IHE Context is confusing when not explained, and mixing references to the SWF profile in the Clinical Context further confuses the intent. 3.4.5 KOD low Fig 3.3-1 implies that starting the procedure on the DSS/OF somehow triggers the worklist query from the modality 3.4.5 KOD low Schedule Procedure text implies that assigning a time slot and equipment are required 3.4.6 KOD low Query Modality Worklist text implies that there is never more than one procedure step scheduled for a patient. 3.4.6 KOD low Fig 3.3-2 doesn't show the corresponding End Procedure. 3.4.7 KOD low Fig 3.3-2 should break the DSS/OF box before the MWL Query. 3.4.7 KOD low Fig 3.3-2 implies that MPPS messages cannot be sent directly to the DSS/OF 3.4.7 KOD high Update Status text says that Modality ID is used to identify the room, but elsewhere the Location attribute is required for that purpose. Which is true? What if they conflict? (Mobile equipment) 3.4.7 KOD high Update Status text says the DSS/OF updates the Scheduled Procedure Steps for all the modalities in that same cath lab but does not define what that means. 3.4.7 KOD low Update Status text is more detailed than the Start Procedure text. 3.4.7 KOD high Has the MPPS exception case where the wrong worklist entry is selected and an initial MPPS is sent been reviewed in the context of using the active procedure for room eqt coordination? 3.4-5 Fig KOD low Fig 3.4-1 needs a break in the DSS Boxes after the Start Procedure and Update Procedure actions App A KOD low Fig 3.4-3 doesn't have a Start Procedure App A KOD high So the concensus is that it is preferable in the Patient ID Update case for the different equipment in the Cath Suite to display different Patient Demographics? App A KOD high The diagram does not show any storage of images/etc from the modalities. There could be confusion about what should be stored, what is stored, and what each system needs to consider to make things that should match match and things that should be unique be unique. General GE-HS PPS Mgr in figures: "... the Performed Procedure Step Manager is not shown on the Process Flow diagrams and is presumed to be grouped with the Image Manager." tsippel There is another potential use case in Cath. It is not clear to me that the Change Rooms use case is teh correct solution, but it may be. This case is the "patient/case diverted to a different room only seconds before patient enters room" case. Needs more thought. tsippel need a Procedure Cancelled Use Case GE-HS Table 3.2-1 should be "Cardiac Cath Workflow" GE-HS Table 4.2-1 should be "Echo Workflow" smm Counting on DSS to schedule procedures is dangerous smm Cath workflow, room change GE-HS 1. Whether an order for a Diagnostic Cath should be replaced by the DSS/OF with an order for a Diagnostic/Interventional Cath. 2. How SPSs can be used - single SPS for Cath, separate SPSs for diagnostic and interventional, etc. 3. How MPPSs can be used - either by completing the diagnostic PPS and starting a new interventional PPS, or by reporting both diagnostic and interventional Protocol Codes in a single PPS - and the implications of each approach. Proposed Resolution Propose as Final Resolution if Accepted (to be filled in by Accepted/Rejecte Comment Editor) d (to be filled in by Comment Editor) Need to understand why the Units of Reject - Discuss at work can’t be broken down so there is a Rad TC 7/12/04 No 1-1 correspondence with the Number of change needed to Requested Procedures. Cardiology TF Should the workflow be presented with a Reject- Discuss at PIR requirements overlay to keep things Rad TC 7/12/04 No consistent. The requirements of PIR change needed to appear to be consistent. There are just Cardiology TF more of them. Reword the last sentence. This idea of Accept - change not fully utilizing the three level is Harry to work on restated several time without being rewording. explained. I suggest that the three levels are always used. No need to discuss in Vol I the missing information (e.g. no SPS) in some cases. make it "R" in Table 3.2-1 Reject Divide this section into two sections to Accept - elaborate discuss portions of Scheduled Workflow better in sec 3.2 which are required for Cath Workflow, or (same change for add verbiage into the section and Echo 4.2) rename the section and the table. Is this discussion out of scope for the Reject - Public Comment? Propose that the requirements are optionally be maintained, but that based on the verbiage be used to indicate the needs of cardiology importance of their support. Either remove the "optionality" column Accept - elaborate from the table or clearly explain what it better in sec 3.2 means to have an "option" that's (same change for required. Echo 4.2) The following is a suggestion which Reject This is not would need to have all the elements an unscheduled worked through: Use the Scheduled case it is a Procedure as a “seed”, but then scheduled case discontinue and create an unscheduled and is the same as MPPS with the real parameters. These Radiology two elements could be used by the DSS/OF to accomplish the scheduling of the remaining pieces (how would again be out of scope for IHE as it is internal to a single actor). There are a number of parameters (Requested Procedure, Study UID, etc. which will need to be specified to ensure that the links are all maintained. Remove the strengthening requirement Reject - not a for Broad Query Support. requirement. Recommendation would be acceptable. "may" suggests it is an option. The Image Manger/Archive must support Reject - all of the DICOM SOP Classes required conformance to to support the Cardiology Workflow. It is Cath option is expected that this be documented by a required reference in the IHE Integration Statement (Appendix D of RAD TF Vol 1). Suggestion that the MPPS In-Progress Accept - but text and Complete section be put so that the improved in regard interaction between the start and to multimodality complete explain the entire interaction completeness uninterrupted. Remove this section. If it is felt this is Reject - needed in critical to state, it can be placed in one of Card vol 1 the Use Cases. Is this the “Performed Station Name”, Accept - use “Performed Station AE”, “Modality” or Performed Station something else? AE Replace by: “so there needs to be a way Accept - change for all of the participating modalities to patient and coordinate and to share specific procedure information.” information Change title of 3.3 to Cath Scheduled Accept - change Process Flow. And remove Case C1 in name 3.4 which is almost entire duplication. WE should advise that DSS provide a Duplicate means to indicate that the current Start/Stop procedure is "complete" wrt the Improved in 3.3 acquisition modalities in that room. This rewording is no more than recognition of existing functionality in most practical DSS implementations. Other automated- based alternatives via linking this to generation of another "unexpected" MPPs-in-progress (with another patient ID) may be impractical, especially as the number of cath-lab modalities and their time-based interaction grows. Remove this activity from the Framework Same start or propogate it to other systems (only if it procedure is needed by another system). discussion - Improved in 3.3 rewording I don't see how you can make this Accept - remove implementation statement. word enterprise it should be an indented note (or a Accept improved separate para in bold) to set it off text I believe that there needs to be a Accept sentence immediately following the sentence listed above which also states "the MPPS transactions for the other "n" modalities are not included in the diagrams for the sake of simplicity…." Re-word to indicate that only the process Reject wording is control workflow are shown in this the same as RAD section. Then specifically state that the TF 4.4.1; There is PPS is not shown because it is assumed no critical grouping. that it is grouped. Grouping was already discussed. If there is something critical about the grouping it should have been stated in the transactions section. make optional or required. Accepted - text changed add use case # to figure titles Accept Why wouldn’t this be included for Reject - part of Cardiology? reporting Why wouldn’t this be included for Reject - part of Cardiology? reporting This is probably just an omission as the Accept transaction appears in Figure 3.1-1 make consistent, but is it worth it? Accept - change needs discussion. Should they be Reject seperated? Meaning a line should be between Image Manager and Image Archive because they could be separate devices? Add Patient Updated RAD 12 to the table Accept - change Break this in two tables. Reject Better to show differences using bold, Reject special text or lines (or some other indicator) so it is visible in black and white print. Accept - update clinical context of 3.3+G22 Accept - duplicate Reject Accept Add a sentence immediately prior to Accept - improve table 3.4-1 which says something to the text 3.3 clinical effect of "Today Case C3 and Case C5 context are by far the most common. It is the intent of this Profile to move towards the Cases C1 and C2." or something more eloquent. delete it. Reject IHE Context: Case2 is currently Reject - duplicate supported by RAD Scheduled Workflow of completeness receive and cancel. Reference the SWF 'order replacement Accept - with by the DSS/OF' case and PIR case #2. reference add sentence Accept - update use of Procedure codes in 3.4.3 Should there be the concept of a Reject- Answered standing Procedure (Temporary) just like in vol 2 sec 4.1.1 there is a standing Patient ID (Temporary)? bullet the two differences discussed. Accept Is this the “Performed Station Name” or Accept - use something else? Performed Station AE put it in 1 place with an identifier and Reject refer to it. Give it a special use-case. Describe who generates the study Reject instance uid. Provide a description of the workflow as Reject - Specific to a case. If necessary expand the PIR Radiology Profile to include all of the Cardiology Workflow. Add the order status update transaction Accept - also to the end of this use case. needed in cases 4 and 5. Transaction also needed in RAD strengthen sentence by adding Reject - has to be something to the effect of 'all cases for manual patient reconciliation should be queued reconciliation (retained?) for future resolution.' Add the order status update transaction Accept - also to the end of this use case. needed in cases 4 and 5, others. Transaction also needed in RAD Accept - reword 3.4.3 and 3.4.5 notes by emphasizing that time lags are minimal - minutes not hours. See comments above regarding the Reject - single structuring of PIR and Workflow. profile in Cardiology change it. Accept in first para of IHE Context, last Accept sentence: add "…treated as a single Requested Procedure, ie., the same Study Instance UID." Need to include concrete examples with Accept - add in what information goes into the IODS and tables the MPPS. I would like a discussion of scheduling Reject - no the procedures to take place in the case additional modality where the patient may get moved to support is needed. another room. It would be nice if the the IHE Technical Reject - timing is Framework stated exactly which modality not relevant, every is responsible for sending the MPPS modality has to Discontinued message when a room send a discontinue change occurs. or complete before next case. Agreed. Quick fix. Accept - need more words for end procedure. Explain that use cases will first present Accept the "Clinical Viewpoint" to establish the needs from a clinical users point of view, then the "IHE Viewpoint" will present how the situation is modelled in this technical framework and what the solution is. Consistency with this should be reviewed in each Clinical/IHE section. The Start Procedure should be a Accept separate box in the flow diagram. Change Text to: Scheduled Procedure Reject - must have Steps are scheduled, i.e., placed on the time and AE title worklist, possibly with an assigned time for MWL slot and/or performing resource (modality). Change Text to: (provided with sufficient Accept query keys to get back the scheduled procedures for a single patient) Since Start Procedure was called out in Accept/Duplicate the diagram, End Procedure should be included too. Accept Add a note explaining that this diagram Accept shows the IM receiving the MPPS messages and forwarding to the DSS, however it is also valid to send the MPPS to the DSS and it will forward to the IM. Choose one an update text accordingly. Accept/Duplicate Clarify what attributes of the SPSs must Accept - need be updated; where the updated values elaboration should come from; what to do if they conflict with existing values; how the DSS knows what modalities are in that cath lab at this moment. Consider using the "first MPPS triggers Reject - point of Start Procedure" as the base case then fact start procedure model the other as the manual or non- happens modality method to do the same thing. significantly sooner And make sure the above issues are still than MPPS addressed. If not, should review Accept - need reference to text within Radiology MPPS transactions. Exceptions Management Sec 3.3.4 (And repeat for subsequent diagrams) Accept Since actions are identified with Start Reject - C3 is Procedure, it should be included unless started by MPPS the intention that those actions not take not Start Procedure place in this scenario. Not saying that's wrong, just want to be Reject - consistant clear. If the choice is to show the same with Radiology id, either we would need to do messy implementation of stuff to get the first modality update (not Patient Update a great option) or tell the DSS not to update the worklist, then all equipment shows the temporary name. Consider and update diagram and text. Reject - diagrams are drawn to emphasize the use case. Add to the Image Manager label at the Accept change top of each flow diagram "/PPS label not diagrams Manager" Reject - normal workflow I believe that we need to look in more Accept - create detail at a Procedure Cancelled use case new C8 at least in Cath, possibly in Echo also. It is very important to the workflow of the department to retain information about why/by whom/when it was cancelled so that the flow manager is not incessantly asked "where is patient so-and-so?". Accept Accept Cath workflow for procedures not Reject - Note on ordered counts on the DSS to schedule timing was added procedure steps in response to the first MPPS message from a modality. Then, you have to wait an undefined time for the DSS to perform this. You have similar problems for the case when the patient is registered and unregistered.Why not have the DSS schedule one patient with an internal patient ID for each cath room. This is the waiting list patient that you process when you don't have time to register/order anything. This means that all modalities in the room get the same Study Instance UID. Even if the patient is registered and there is no order information, you can still process the "dummy" patient. You will just have the manual step of reconciling this patient with the registered patient. This is not a big loss as there are lots of manuals steps here, anyway. Even if the patient is registered and there is no order information, you can still process the "dummy" patient. You will just have the manual step of reconciling this patient with the registered patient. This is not a big loss as there are lots of manuals steps here, anyway. Case C7 has the department changing rooms because of equipment malfunction or when the diagnostic case turns into an interventional case. The specification says that someone will have each piece of equipment in the room (possibly malfunctioning) send a discontinued message to the DSS. What person in the room is going to do this. From the malfunction issue and the human workflow issue (will the last person in the room toggle all the equipment), this does not make sense.
Pages to are hidden for
"Master Cath Comments_3.xls - IHE"Please download to view full document