This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

OO Dynamic Model Minutes

From HL7Wiki
Revision as of 15:12, 12 May 2006 by Hbuitendijk (talk | contribs)
Jump to navigation Jump to search

<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.
    • 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

    b== 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.
    • Question: can we combine the suspend and resume in one message? TBD.

    <Orders & Observations TC> <OO Dynamic Model>