VIEWS: 0 PAGES: 30 POSTED ON: 9/30/2013
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, 3.1-1 why 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 3.1-1 say 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 TDO grammar Note - the differences between the 3.3-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 3.4-1 get 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. General Siemens Medium Inconsistent content in the the chapters "Significiant Transactions". They contain sometimes transaction and some time general information. page 22 Siemens Medium Many of these transaction diagrams (figure 3.1- have image manager and image 1) 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.2-1, 4.2- Siemens High Please Clarify the ambiguity 1 (optionality column in tables 3.2-1, 4.2- 1). Options cannot be required, then they are no longer options 3.3 Siemens Low Section title "Scheduled process flow" and figure legends of figures 3.3-1, -2 seem not fully appropriate. p.26 Siemens Medium Application functionality described - these implementation-specific statements may distract from the important transaction aspects: 1) "Start Procedure" bullet: the DSS's optional function to start the Cath procedure seems do describe application functionality. What is the transaction principle behind - this is unclear. Why should the DSS have the ability to set a SPS on arrived? In DICOM there are several "arrive" states like for Scheduled Procedure Step Status, Study Status ID and Study Arrival Date. Which will be set with "arrived": the worklist arrived at the modality, the patient arrived at the department or modality? 2) "Select Patient" bullet: "a modality may optimize" - this is internal behavior of an actor which is out of scope of IHE. 2) "Query MWL" bullet (p.27): this seems to be an implementation- specific statement, which gives the impression of required behavior. fig. 3.3-2 Siemens Low Acquisition Modalitites 1..n: make (and clear that n>1 acqu. Mod. Can occur following fig.s) 3.4 Siemens High The basic assumption behind alll the 6 defined use cases is that each of the partcipating modlaity in the cathlab performs separate individual worklist query to DSS/OF for the respective scheuled procedures. But in a integrated recording & imaging system lab , one of the integrated modality will acts as the interface to the external world such that it will make the MWL and also will send the PPS info back. at the same time images are archived by both the integrated modalities . for e.g HEMO system and an imaging system acting as one integrated modality with HEMO interacting with the external world.In this scenario HEMO system initiates the MWL , updates the PPS info and archives only the waveform objects it creates . the images are direclty archived by the imaging system. 3.4 Siemens Medium There are cases where only a subset of images acquired (dut to some artifacts like motion error or the patient moved during the exam) are archived , but the image manager expects all the acqired images based on the information received from PPS manager. So theer shall be a mechnism to update the image manager with the correct number of images that are archived. 3.4 Siemens Medium Section 3.4 is difficult to understand because the use cases are similar and overlapping. The events/transactions of Acquisition Modality n are not completely shown in most diagrams. 3.4-4 p.34 Siemens Medium Unscheduled Performed Procedure Step is mentioned, references to RAD TF are missing page 37 Siemens Low I'd prefer to have a reminder in the (figure 3.4- legend of the figure as to what Case is 5) being displayed. In this figure, simply say "Figure 3.4-5. C-5. Patient not registered" 3.4 -4, 5, Siemens High Patient Update functionality at the 6Case modality , for the possibilty of the :C4, C5 & creation of an exchange media with C6. corrected data. Same is true for printing from the modality with . Fig. 3.4-5 Siemens High During Procedure Patient data is also in Modalities and needs to be updated so that any subsequent data being sent to the image manager goes with the correct data. 3.4.6 Siemens Different patient demographic data are available on the different modalities due to patient update during procedure.How schould the user handle them in case of burn on exchange media or print outs 3.4-7, Siemens Medium Case C7 relies on the possibility that Page 39 the first modalities can set the MPPS Case C7 status to discontinued. That is not the case during equipment failure. 3.4.7 Siemens Medium The procedure Cancelled scenario not defined in detail in any of use cases. 3.4.7 Siemens Low The equipment failure example does not seem to be a good one, and seems superfluos after the "change to intervention" example. Proposed Resolution Propose as Final Resolution if Accepted (to be filled in Accepted/ by Comment Editor) Rejected (to be filled in by Comment Editor) Need to understand why the Units of Reject - Discuss work can’t be broken down so there is a at Rad TC 7/12/04 1-1 correspondence with the Number of No change needed Requested Procedures. to Cardiology TF Should the workflow be presented with Reject- Discuss at a PIR requirements overlay to keep Rad TC 7/12/04 things consistent. The requirements of No change needed PIR appear to be consistent. There are to Cardiology TF just 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 - discuss portions of Scheduled elaborate better in Workflow which are required for Cath sec 3.2 (same Workflow, or add verbiage into the change for Echo section and rename the section and the 4.2) 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 importance of their support. cardiology Either remove the "optionality" column Accept - from the table or clearly explain what it elaborate better in means to have an "option" that's sec 3.2 (same required. change for 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 MPPS with the real parameters. These as 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 Reject - support all of the DICOM SOP Classes conformance to required to support the Cardiology Cath option is Workflow. It is expected that this be required documented by a 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 improved in regard the 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 Card vol 1 of 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 Accept - change way for all of the participating patient and modalities to coordinate and to share procedure specific 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 Start/ means to indicate that the current Stop Improved in procedure is "complete" wrt the 3.3 rewording acquisition modalities in that room. This 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 Same start Framework or propogate it to other procedure systems (only if it is needed by another discussion - system). 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 Reject wording is process control workflow are shown in the same as RAD this section. Then specifically state TF 4.4.1; There is that the PPS is not shown because it is no critical assumed that it is grouped. Grouping 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 Accept - change table 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 text 3.3 clinical the effect of "Today Case C3 and Case context C5 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 in vol 2 sec 4.1.1 like 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 a case. If necessary expand the PIR to 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 Accept - add in with what information goes into the tables IODS and the MPPS. I would like a discussion of scheduling Reject - no the procedures to take place in the additional modality case where the patient may get moved support is needed. to another room. It would be nice if the the IHE Technical Reject - timing is Framework stated exactly which not relevant, every modality is responsible for sending the modality has to MPPS Discontinued message when a send a discontinue room 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 time and AE title the worklist, possibly with an assigned for MWL time 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 Accept - need must be updated; where the updated elaboration values 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 model the other as the manual or non- procedure modality method to do the same thing. happens And make sure the above issues are significantly still addressed. sooner than MPPS 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 place in this scenario. Procedure Not saying that's wrong, just want to be Reject - consistant clear. If the choice is to show the with Radiology same id, either we would need to do implementation of messy stuff to get the first modality Patient Update update (not 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 new C8 case 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. Reject Reject - Required to be grouped by Radiology Include required options in Table 3.2-1. Accept - Duplicate If "required optionalities" are always required, then this is a real required transaction part, which should occur in table 3.1-1, marked "R", perhaps having an explaining note as well. In the corresponding vol.2/3 transaction chapter, the corresponding section should clearly state that this transaction part is only required for the CARD TF. Finally, the table 3.2-1 column can be removed. This principle can be used for the Echo workflow as well. Perhaps improve to "Cath process Accept - fixed scheduling". Clarification Needed: Accept - will clarify 1) explain the transaction principle in TF 2) remove this internal behaviour description 3) remove this statement completely, as there are different query options rename the diagram column Accept - will add "Acquisition Modality" to "Acquisition in clarification Modality 1" Clearly Understand the user need & Reject - IHE works acceptance to the "single modality to implement worklist query" model where each multivendor participating modality in a Cathlab integration. workflow makes separate independent Modality worklist query . Automatic verification of study via Reject - no MPPS (synchronization between proposed solution images sent from the modality and in RAD - propose images received in PACS).· The fact CP to Radiology if that images that were acquired will not desired be sent to PACS is not yet considered in IHE RAD technical framework and therefore there exists currently no proposed solution for that particular problem Shorten and simplify this section. Avoid Reject - editors repetitions. Make clear the critical have reviewed and differences between the use cases. It made some seems sufficient to have less text while modifications. keeping the diagrams in use cases that are based on other use cases. Patient reconciliation does not seem necessary to be repeated in case 2 and 3 (reference should suffice). Explain what is shown for Acquistion Modality n (i.e. explain the incomplete flow). Accept - references are added to top of 3.4 Accept - done Make a decision on the fact that Rejected - by IHE, without the Patient Update functionality expected to be at the modality , the Patient data at the done from Image first modality is not correct and so Manager alowed to exist without propr updation. Add Update Patient in Modality Rejected - by IHE, expected to be done from Image Manager Rejected - by IHE, expected to be done from Image Manager Make clear note that equipment failure Accept - done will result in no "Reassign Procedure" ath the DSS/OF. The modalities in the new room have to work with the original Scheduled Procedure Step in this case. Accept - added case 8 remove this example Reject - Xray tubes fail during exams.
Pages to are hidden for
"Master Cath Comments_4"Please download to view full document