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 12: Line 12:
 
Note that a referral is patient care provision in order mood.</li>
 
Note that a referral is patient care provision in order mood.</li>
 
=== Approach ===
 
=== 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>
 
<ul>
<li>Revise Active</li>
+
<li>This wiki page will be used to focus our discussions.</li>
 +
<li>We agreed to use the Publishing Database directly to maintain the necessary ballot components (Storyboards, Interactions, Trigger Events, Application Roles, State Transitions) and Visio for the Activity Diagrams.</li>
 +
<li>Creating ballotable artifacts will be the main driver, while the decisions and notes from the minutes will be input into the documentation</li>
 +
<li>For the state machine we will start with the currently defined general state machine and then specialize the definitions and descriptions for Orders & Observations.
 
</ul>
 
</ul>
<li>Motion to accept both “Discontinue …” and “Shortening…” bullets.</li>
+
Michael van Campen and Garry Cruickshank will drive populating the Publishing Database based on our input, while Wendell Ocasio will put the initial Activity Diagrams into Visio based on our input.
<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 -->
Line 113: Line 30:
  
 
== Story Boards ==
 
== Story Boards ==
 +
Tom de Jong and Rob Hallowell will provide the 2 storyboards that will get us started.
  
 
== Activity Diagrams ==
 
== Activity Diagrams ==

Revision as of 15:45, 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 use the Publishing Database directly to maintain the necessary ballot components (Storyboards, Interactions, Trigger Events, Application Roles, State Transitions) and Visio for the Activity Diagrams.
      • Creating ballotable artifacts will be the main driver, while the decisions and notes from the minutes will be input into the documentation
      • For the state machine we will start with the currently defined general state machine and then specialize the definitions and descriptions for Orders & Observations.

      Michael van Campen and Garry Cruickshank will drive populating the Publishing Database based on our input, while Wendell Ocasio will put the initial Activity Diagrams into Visio based on our input.

Story Boards

Tom de Jong and Rob Hallowell will provide the 2 storyboards that will get us started.

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>