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

Difference between revisions of "OO Behavioral Model"

From HL7Wiki
Jump to navigation Jump to search
Line 2: Line 2:
 
|-
 
|-
 
| style="vertical-align:top" | <!-- LEFT COLUMN -->
 
| style="vertical-align:top" | <!-- LEFT COLUMN -->
−
== Project Objectives ==
+
== Project Objectives & Introduction ==
 +
The objective of the Dynamic Model project is to initially focus on common set of rules on how to deal with order management state transitions after the creation of an order.  This will cover Lab, Rx, Rad, PT, Dietary, NRS, Procedures, etc.
 +
<p>
 +
Subsequently we will focus on:
 +
<ul>
 +
<li>Create set of rules on how to deal with observation state transitions</li>
 +
<li>Synchronize with referrals and appointments.</li>
 +
<ul>
 +
Note that a referral is patient care provision in order mood.</li>
 +
=== Approach ===
 +
This wiki page will be used to focus our discussions.  We agreed to
 +
 
 +
However, since the materials need to end up in the Publishing Database, we have to determine how to best balance what to document initially here and when to populate the Publishing Database.  During our meetings we will primarily focus on enhancing the Publishing Database content.
 +
<p>
 +
Activity Diagrams will be documented using visio diagrams.
 +
<p>
 +
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).</li>
 +
<ul>
 +
<li>Left to Right or Right to Left?</li>
 +
<li>Do they all end up in the ballot and therefore, do we need to do them?</li>
 +
</ul>
 +
<li>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.</li>
 +
<li>Tom and Rob to provide initial story boards.</li>
 +
<li>Michael/Garry C initial “pub drivers”</li>
 +
<li>Wendell initial “visio driver”</li>
 +
</ul>
 +
</ul>
 +
<li>Issue: “Combined State Transitions”</li>
 +
<ul>
 +
<li>Examples:</li>
 +
<ul>
 +
<li>Suspend/Resume – one focal act, two state transitions</li>
 +
<li>Replace – one focal act and non-focal act, each with their own state transition</li>
 +
</ul>
 +
<li>Do not want to send two messages for the Replace.  MnM must support, or we’ll ignore them.</li>
 +
<li>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.</li>
 +
<ul>
 +
<li>'''Discussion:''' None.
 +
<li>'''Vote:''' Against: 0; Abstain: 0; In Favor: 15</li>
 +
</ul>
 +
</ul>
 +
b== San Diego, January 2006==
 +
<ul>
 +
<li>'''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.</li>
 +
<ul>
 +
<li>Extension can be dealt with in a couple of ways:</li>
 +
<ol>
 +
<li>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.</li>
 +
<li>Change the stop date/time to the new stop date/time.</li>
 +
<li>Create a new order for the period after the existing stop date/time.</li>
 +
<li>Replace the entire existing order and then enter a new order “retroactively”.</li>
 +
</ol>
 +
<li>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.</li>
 +
<li>We agree that 1 and 4 should not be used for this scenario.</li>
 +
<li>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.</li>
 +
<li>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.</li>
 +
<ul>
 +
<li>Vote: Against: 0, Abstain: 2, In Favor: 9</li>
 +
</ul>
 +
</ul>
 +
<li>'''Issue:''' Discontinue of an order “now” that had an open-ended date or specific future date/time.</li>
 +
<ul>
 +
<li>Complete or Abort depending on whether the discontinuation is “abnormal”</li>
 +
</ul>
 +
<li>'''Issue:''' Shortening or changing a stop date/time from “undetermined” or specific date/time to a specific, but closer future date/time.</li>
 +
<ul>
 +
<li>Revise Active</li>
 +
</ul>
 +
<li>Motion to accept both “Discontinue …” and “Shortening…” bullets.</li>
 +
<ul>
 +
<li>'''Vote:''' Against: 0, Abstain: 1, In Favor: 10.</li>
 +
</ul>
 +
<li>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.</li>
 +
<li>Gunther to dump minutes related to Dynamic Model into the Wiki and start building onto that.</li>
 +
<li>'''Issue:''' Refinement Discontinue bullet:</li>
 +
<ul>
 +
<ul>
 +
<li>If the effective stop date/time is changed to “now” and/or reached, then the order is complete.</li>
 +
<li>If the effective stop date/time is not changed and the order is discontinued, then the order is aborted.</li>
 +
</ul>
 +
<li>A pre-condition is a filter to the execution of the order, but not an indication of the status of the order.</li>
 +
<li>Motion to accept.</li>
 +
<ul>
 +
<li>'''Vote:'''  Against: 0; Abstain: 4; In Favor: 11</li>
 +
</ul>
 +
</ul>
 +
<li>'''Issue:''' Refinement Shortening bullet.
 +
<ul>
 +
<li>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.</li>
 +
<li>Motion to accept.</li>
 +
<ul>
 +
<li>'''Vote:''' Against: 0; Abstain: 4; In Favor: 13.</li>
 +
</ul>
 +
</ul>
 +
<li>Question: can we combine the suspend and resume in one message?  TBD.</li>
 +
</ul>
 +
 
 +
<[[Orders & Observations TC]]> <[[OO Dynamic Model]]>
 +
 
 +
 
  
 
| style="vertical-align:top" | <!-- RIGHT COLUMN -->
 
| style="vertical-align:top" | <!-- RIGHT COLUMN -->

Revision as of 15:32, 12 May 2006

Project Objectives & Introduction

The objective of the Dynamic Model project is to initially focus on common set of rules on how to deal with order management state transitions after the creation of an order. This will cover Lab, Rx, Rad, PT, Dietary, NRS, Procedures, etc.

Subsequently we will focus on:

  • Create set of rules on how to deal with observation state transitions
  • Synchronize with referrals and appointments.
      • Note that a referral is patient care provision in order mood.

      Approach

      This wiki page will be used to focus our discussions. We agreed to

      However, since the materials need to end up in the Publishing Database, we have to determine how to best balance what to document initially here and when to populate the Publishing Database. During our meetings we will primarily focus on enhancing the Publishing Database content.

      Activity Diagrams will be documented using visio diagrams.

      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>


    Story Boards

    Activity Diagrams

    Interactions

    Trigger Events

    Application Roles

    State Transition Definitions

    Dynamic Model Minutes

    To get access to just the Dynamic Model related minutes from past O&O meetings, please click here.

    <Orders & Observations TC>

    Retrieved from "https://wiki.hl7.org/w/index.php?title=OO_Behavioral_Model&oldid=3454"