OO Dynamic Model Minutes

<Orders & Observations TC> <OO Dynamic Model>

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.
• (Note added to the minutes post-publication: 1 trigger event can cause multiple acts to change state, this is not limited to a state change of the focal act. This was clarification provided by MnM on this topic. See Trigger Event. Note added by Rene spronk 11:41, 13 May 2006 (CDT))
• 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.
• (Note added after the meeting and creation of minutes: a ControlAct in the domain payload could be in RQO mood, but oinly in very spefific use cases. Suggest that those be documented. By default all ControlActs have an EVN mood. Note added by Rene spronk 11:44, 13 May 2006 (CDT))
• 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.
• Question: can we combine the suspend and resume in one message? TBD.

<Orders & Observations TC> <OO Dynamic Model>