OO Dynamic Model Minutes

bb== San Antonio, May 2006 ==

• Project Team
• We seem not to be able to get a project team going to focus on the Dynamic Model that cuts across the different areas.
• Should we consider an out-of-cycle, e.g., Sunday prior, or Friday, on Dynamic Model?
• Should we focus on creating documentation rather then just making decisions?
• Hans to send out request for interest to meet on Sunday prior or Friday for a full day.
• Objectives
• Initially focus on common set of rules on how to deal with order management state transitions after the creation of an order.
• Covers lab, Rx, Rad, PT, Dietary, NRS, Procedures, etc.
• Subsequently:
• Create set of rules on how to deal with observation state transitions
• Synchronize with referrals and appointments.
• Referral is patient care provision in order mood.
• Wiki
• We agreed to use the wiki site to channel discussions.
• Hans to populate raw data. Notes and initial seed of the documentation
• Copy-n-paste the general act state machine as well.
• Documentation
• We should take current state machine of act and elaborate under the common order model.
• Alternatively, we can use storyboards as starting point.
• We need to provide both the storyboards and state machine.
• Approach
• Should we use the HDF approach to generate the artifacts necessary?
• Should we go back to the topics discussed to date and start to go for each one of them and start to produce these artifacts and refine our approach?
• We agreed to address Storyboard (wiki/pub db), Activity Diagram (visio), Interaction (pub db), Trigger Events (wiki/pub db), Application Roles, State Transition Definition. (those in bold are needed for ballot).
• Left to Right or Right to Left?
• Do they all end up in the ballot and therefore, do we need to do them?
• Consider listing/prioritizing all topics, or take 1-2 storyboards and flesh them out completely. The latter would not touch all topics, but complete all necessary steps.
• Tom and Rob to provide initial story boards.
• Michael/Garry C initial “pub drivers”
• Wendell initial “visio driver”

Issue: “Combined State Transitions”

• Examples:
• Suspend/Resume – one focal act, two state transitions
• Replace – one focal act and non-focal act, each with their own state transition
• Do not want to send two messages for the Replace. MnM must support, or we’ll ignore them.
• Motion: Suspend/Resume – two messages are consistent with V2. Until clear use case to combine, suggest to stay with two messages. Tom moved, Rob second.
• Discussion: None.
• Vote: Against: 0; Abstain: 0; In Favor: 15

San Diego, January 2006

• Issue: Do we need to make a difference between a extension of the stop date/time into the future, or shortening the stop date/time.
• Extension can be dealt with in a couple of ways:
1. Complete existing order with a stop date/time of “now” and enter a new order with a start date/time of “now” until the new stop date/time.
2. Change the stop date/time to the new stop date/time.
3. Create a new order for the period after the existing stop date/time.
4. Replace the entire existing order and then enter a new order “retroactively”.
• However this needs to look different from a scenario where the current order must be stopped due to clinical objectives not be met and “replaced” with another order.
• We agree that 1 and 4 should not be used for this scenario.
• There was much discussion whether to get to one option or whether to accept two ways of communicating the extension depending on the system’s capabilities.
• Motion to support options 2 and 3 now, recognizing that 1 and 4 do not have enough use case support to justify addressing at this point in time.
• Vote: Against: 0, Abstain: 2, In Favor: 9
• Issue: Discontinue of an order “now” that had an open-ended date or specific future date/time.
• Complete or Abort depending on whether the discontinuation is “abnormal”
• Issue: Shortening or changing a stop date/time from “undetermined” or specific date/time to a specific, but closer future date/time.
• Revise Active
• Motion to accept both “Discontinue …” and “Shortening…” bullets.
• Vote: Against: 0, Abstain: 1, In Favor: 10.
• Mood code on the trigger event ControlAct is always in Event mood (because MnM so decreed), while in the case of a request we’ll introduce a Request ControlAct in the Payload, but not in the case of a notification.
• Gunther to dump minutes related to Dynamic Model into the Wiki and start building onto that.
• Issue: Refinement Discontinue bullet:
• If the effective stop date/time is changed to “now” and/or reached, then the order is complete.
• If the effective stop date/time is not changed and the order is discontinued, then the order is aborted.
• A pre-condition is a filter to the execution of the order, but not an indication of the status of the order.
• Motion to accept.
• Vote: Against: 0; Abstain: 4; In Favor: 11
• Issue: Refinement Shortening bullet.
  • If we send a future discontinue (abort) without changing the overall effective stop date/time, we should send an order with a control act in event mood with a future date/time. When the date/time is reached, the state changes to abort.
  • Motion to accept.
  • Vote: Against: 0; Abstain: 4; In Favor: 13.
• Questtion: can we combine the suspend and resume in one message? TBD.