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

Difference between revisions of "Act in DEF Mood"

From HL7Wiki
Jump to navigation Jump to search
Line 37: Line 37:
 
Remove DEF, CRT and EVN.CRT from ActMood.  The remaining codes in ActMoodPredicate should be considered as candidate abstractions.  Initial analysis suggests that both GOL and RSK are in fact "normal" moods as they have assigned subjects, times that are expected, etc.  (Phrased another way, one can envisage a DEF for a Goal.)
 
Remove DEF, CRT and EVN.CRT from ActMood.  The remaining codes in ActMoodPredicate should be considered as candidate abstractions.  Initial analysis suggests that both GOL and RSK are in fact "normal" moods as they have assigned subjects, times that are expected, etc.  (Phrased another way, one can envisage a DEF for a Goal.)
  
   
+
==Changes in ''"Rules"'' ==
+
*For all Acts whose abstractionCode is "NORMAL", the rules according to DocumentCharacteristic, and existing RIM definitions apply.  
 +
*For all Acts whose abstractionCode is not "NORMAL", every attribute, and association of that Act is interpreted as being part of the criterion or definition.
 +
*In order to document the life cycle and responsibilities surrounding a set of elements not in "NORMAL" mood, these classes must stem from a "NORMAL" class (such as RQO or GROUPER) that packages these elements.
 
==Previous Recommendations==
 
==Previous Recommendations==
 
[1] Document characteristic attributes: Current thinking is to assume that in EVN.CRT mood, no properties are documentation characteristic. Gunther suggests that we may need to split Act.statusCode into an Act.actStatusCode and an Act.recordStatusCode.  
 
[1] Document characteristic attributes: Current thinking is to assume that in EVN.CRT mood, no properties are documentation characteristic. Gunther suggests that we may need to split Act.statusCode into an Act.actStatusCode and an Act.recordStatusCode.  
  
 
[2] Vocabulary binding: Current thinking is to include a local code, which in the local code system reflects a value set.
 
[2] Vocabulary binding: Current thinking is to include a local code, which in the local code system reflects a value set.

Revision as of 17:37, 22 September 2009

Introduction

Various challenges with using DEV (or EVN.CRT) mood have been identified. These are detailed here: http://wiki.hl7.org/images/d/d1/EMeasureMNMPresentation_17July2009.pdf

Defining the Issue

(From M&M discussions Q2 in Atlanta, and others)

DEF and CRT mood are not usable as Mood Codes because the usual rules around the meaning of participations and Act attributes inevitably lead to conflict. For example, as things presently stand:

  • How do I DEF a test that can only be ordered by an RN? I cannot since I cannot use other mood codes, and the author is the one who authored the definition.
  • How do I create a CRT for a class in "INT" mood? I cannot unless I add a new mood INT.CRT.
  • How do I specify a DEF for an ACT that should be created in "suspended" status? I cannot since status belongs to the DEF, unless I create a second status attribute, as GS suggests below.
  • If there is a need for both EVN.CRT and CRT, is there not also a need for everyOtherMoodCode.CRT?
  • How do I include the requirement that the author of an Act not be the subject? I cannot unless we create another "flavor" of the author Participation.

Initial Analysis

The presence the need for "paired" attributes - two flavors of author participation, paired mood codes like EVN.CRT, two flavors of statusCode - are prima facia evidence that there are two different states present that are been collapsed into one. I submit that the distinction is between Acts that are "normal" and will represent real world artifacts (INT, EVN, GOL) and acts that are an "abstract definition" of that reality like "DEF", "CRT", "EVN.CRT". From eMeasures, it has become clear that criteria must exist in all moods and involve all reasonable participations. There seem to be similar requirements for DEF Acts. That being the case, this is not manageable so long as DEF and CRT are mood codes and so long as Act attributes and associations must be relegated to either document characteristic or not.

Recommendations

Two recommendation items were added before 2009-09-21. These have been moved to a Previous Recommendations subsection. What follows was developed subsequent to that date.

New Act Attribute - abstractionCode

Add a new attribute to Act with a sort order that places it immediately after moodCode. The name is "abstractionCoe" with definition like "Determines whether the the Act is a normal act that will instantiated in real record elments or is an abstraction that defines or creates criteria about such normal acts."

This attribute should be Mandatory.

There should be three codes: "NORMAL", "DEF" and "CRT". with a default value of "NORMAL".

Changes in ActMood

Remove DEF, CRT and EVN.CRT from ActMood. The remaining codes in ActMoodPredicate should be considered as candidate abstractions. Initial analysis suggests that both GOL and RSK are in fact "normal" moods as they have assigned subjects, times that are expected, etc. (Phrased another way, one can envisage a DEF for a Goal.)

Changes in "Rules"

  • For all Acts whose abstractionCode is "NORMAL", the rules according to DocumentCharacteristic, and existing RIM definitions apply.
  • For all Acts whose abstractionCode is not "NORMAL", every attribute, and association of that Act is interpreted as being part of the criterion or definition.
  • In order to document the life cycle and responsibilities surrounding a set of elements not in "NORMAL" mood, these classes must stem from a "NORMAL" class (such as RQO or GROUPER) that packages these elements.

Previous Recommendations

[1] Document characteristic attributes: Current thinking is to assume that in EVN.CRT mood, no properties are documentation characteristic. Gunther suggests that we may need to split Act.statusCode into an Act.actStatusCode and an Act.recordStatusCode.

[2] Vocabulary binding: Current thinking is to include a local code, which in the local code system reflects a value set.