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
 
(14 intermediate revisions by 2 users not shown)
Line 12: Line 12:
 
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
 
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
  
= Recommendations =
+
= Status =
 +
At the Face-to-face meeting Q3 , Tuesday, September 22, this issue came very close to being '''Resolved'''.  A solution was outlined, as is documented below.  There was an M&M Motion to endorse this strategy, with no sense that we should follow a different track, but there was also a desire to leave this solution '''''Open''''' on the Wiki for a few weeks, and take a final resolution motion at the time that a Harmonization Proposal is prepared for the November 2009 RIM Harmonization review.
  
 +
The group in attendance reviewed an initial proposal that also "solves" the problem, is a "cleaner" model for the RIM, but that would pose severe backwards compatibility issue to existing implementations and specifications.  This proposal is documented below to demonstrate the alternative that was considered, but is no longer under active consideration.
 +
 +
=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. 
 +
=Endorsed Solution=
 +
This solution is founded on pre-coordinating a set of ActMood codes and attributes that support the modeling of abstractions (definitions and criteria) of the '''''real''''' Acts (particularly those whose mood is in the ''ActMoodCompletionTrack'' hierarchy. Although this is less "clean" than distinguishing an "abstract/real" axis, as suggested in the initial proposal.
 +
 +
Therefore the solution involves the addition of a set of ActMood codes, the addition of two attributes (one each in Act and Participation), and the (re-?)articulation of rules surrounding the meaning of participations as they appear within a criterion.
 +
 +
==Add OpenIssue to ActMood.DEF==
 +
===Rationale===
 +
The M&M discussion raised the question of: "What is the difference between ActMood.DEF and ActMood.CRT?"  The conclusion of the group was that although these are used for different purpose, the purpose is clearly expressed in the ActRelationship that links to these Acts, but in both cases, they are asserting an abstraction of a class to be used as a criterion that serves either for logic or to define such acts.
 +
===Action===
 +
Add an OpenIssue to ActMood.DEF that says: "The semantic constructs embodied in DEF and CRT moods seem indistinguishable, and their uses can readily be determined by the context in which these are used.  Therefore, this OpenIssue has been created to declare that it is likely that ActMood.DEF will be "retired" in the future in favor of the more general ActMood.CRT."
 +
==Add Codes to ActMood==
 +
===Rationale===
 +
In order to facilitate the ability to define criteria on classes in varying primary moods, the set of pre-coordinated ActMoodCriterion sub-types needs to be extended.  The proposed set is felt to be a reasonable sub-set of all mood codes, but others may need to be added in the future.
 +
===Action===
 +
The following list of codes (with their print names and definitions) will be added to ActMood, as specializations of ActMood.CRT:
 +
# RQO.CRT|request criterion| A criterion expressed over requests or orders (ActMood.RQO).
 +
# INT.CRT|intent criterion| A criterion expressed over intents (ActMood.INT).
 +
# PRMS.CRT|promise criterion| A criterion expressed over promises (ActMood.PRMS).
 +
# GOL.CRT|goal criterion| A criterion expressed over goals (ActMood.GOL).
 +
# RSK.CRT|risk criterion| A criterion expressed over risks (ActMood.RSK).
 +
==Add attribute ''recordStatusCode'' to ''Act'' and coordinate with ''Act.statusCode''==
 +
===Rationale===
 +
In order to communicate about the status of a criterion, definition, or even a request, as distinguished from the status of the item being abstracted, defined or requested, one needs a second attribute that can communicate status codes about acts.
 +
===Add attribute  to ''Act'' class===
 +
*'''Name:''' documentStatusCode
 +
*'''Multiplicity:''' 0..1
 +
*'''Data Type:''' CS
 +
*'''Concept Domain:''' ActStatus
 +
*'''isDocumentCharateristic:''' true
 +
*'''Definition:''' '''NEED HELP HERE!!!'''<p>The state of the record that documents the Act.</p><p><b>Rationale: </b>In order to communicate about the status of a criterion, definition, or even a request, as distinguished from the status of the item being abstracted, defined or requested, one needs this second attribute that can communicate status of the record or documentation of the Act (definition, order or criterion) as distinct from the Act.statusCode that reflects the state of the Act itself.</p>
 +
===Change attribute ''Act.statusCode''===
 +
 +
*'''isDocumentCharateristic:''' false
 +
 +
'''[ALL READERS: this was not discussed in Atlanta, but I believe it is a necessary step.  Does it not "break" existing implementations??]'''
 +
==Add attribute ''criterionInd'' to ''Participation''==
 +
===Rationale===
 +
When defining criteria and definitions, it is necessary to be able to include all Participation types as part of the criteria, but the rules in document characteristics assign  the ''isDocumentCharacteristic'' as true for selected participation type codes.  The most notable example relates to the ''AUT'' type code where one would like to write criteria that include characteristics of the author.  This new attribute when ''true'' will assert that this participation is part of a criterion or definition, and thus is not a document characteristic of the act in question.
 +
===Add attribute to ''Participation'' class===
 +
*'''Name:''' criterionInd
 +
*'''Multiplicity:''' 0..1
 +
*'''Data Type:''' BL
 +
*'''Default Value:''' false
 +
*'''Definition:''' <p>This attribute is intended for use in participations of Acts in <i>CRT</i> and <i>DEF</i> moods. It indicates whether or not the Participation is to be used as part of the characteristics of a criterion or definition.  This value over-rides the ''isDocumentCharacteristic'' property asserted for the type code for this participation.</p><p><b>Rationale: </b>When defining criteria and definitions, it is necessary to be able to include all Participation types as part of the criteria, but the rules in document characteristics assign  the <i>isDocumentCharacteristic</i> as true for selected participation type codes.  The most notable example relates to the <i>AUT</i> type code where one would like to write criteria that include characteristics of the author.  This new attribute when <i>true</i> will assert that this participation is part of a criterion or definition, and thus is not a document characteristic of the act in question.</p>
 +
 +
=Initial but Rejected Solution=
 +
==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_resommendations|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) 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.  
 
[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.

Latest revision as of 20:27, 23 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

Status

At the Face-to-face meeting Q3 , Tuesday, September 22, this issue came very close to being Resolved. A solution was outlined, as is documented below. There was an M&M Motion to endorse this strategy, with no sense that we should follow a different track, but there was also a desire to leave this solution Open on the Wiki for a few weeks, and take a final resolution motion at the time that a Harmonization Proposal is prepared for the November 2009 RIM Harmonization review.

The group in attendance reviewed an initial proposal that also "solves" the problem, is a "cleaner" model for the RIM, but that would pose severe backwards compatibility issue to existing implementations and specifications. This proposal is documented below to demonstrate the alternative that was considered, but is no longer under active consideration.

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.

Endorsed Solution

This solution is founded on pre-coordinating a set of ActMood codes and attributes that support the modeling of abstractions (definitions and criteria) of the real Acts (particularly those whose mood is in the ActMoodCompletionTrack hierarchy. Although this is less "clean" than distinguishing an "abstract/real" axis, as suggested in the initial proposal.

Therefore the solution involves the addition of a set of ActMood codes, the addition of two attributes (one each in Act and Participation), and the (re-?)articulation of rules surrounding the meaning of participations as they appear within a criterion.

Add OpenIssue to ActMood.DEF

Rationale

The M&M discussion raised the question of: "What is the difference between ActMood.DEF and ActMood.CRT?" The conclusion of the group was that although these are used for different purpose, the purpose is clearly expressed in the ActRelationship that links to these Acts, but in both cases, they are asserting an abstraction of a class to be used as a criterion that serves either for logic or to define such acts.

Action

Add an OpenIssue to ActMood.DEF that says: "The semantic constructs embodied in DEF and CRT moods seem indistinguishable, and their uses can readily be determined by the context in which these are used. Therefore, this OpenIssue has been created to declare that it is likely that ActMood.DEF will be "retired" in the future in favor of the more general ActMood.CRT."

Add Codes to ActMood

Rationale

In order to facilitate the ability to define criteria on classes in varying primary moods, the set of pre-coordinated ActMoodCriterion sub-types needs to be extended. The proposed set is felt to be a reasonable sub-set of all mood codes, but others may need to be added in the future.

Action

The following list of codes (with their print names and definitions) will be added to ActMood, as specializations of ActMood.CRT:

  1. RQO.CRT|request criterion| A criterion expressed over requests or orders (ActMood.RQO).
  2. INT.CRT|intent criterion| A criterion expressed over intents (ActMood.INT).
  3. PRMS.CRT|promise criterion| A criterion expressed over promises (ActMood.PRMS).
  4. GOL.CRT|goal criterion| A criterion expressed over goals (ActMood.GOL).
  5. RSK.CRT|risk criterion| A criterion expressed over risks (ActMood.RSK).

Add attribute recordStatusCode to Act and coordinate with Act.statusCode

Rationale

In order to communicate about the status of a criterion, definition, or even a request, as distinguished from the status of the item being abstracted, defined or requested, one needs a second attribute that can communicate status codes about acts.

Add attribute to Act class

  • Name: documentStatusCode
  • Multiplicity: 0..1
  • Data Type: CS
  • Concept Domain: ActStatus
  • isDocumentCharateristic: true
  • Definition: NEED HELP HERE!!!

    The state of the record that documents the Act.

    Rationale: In order to communicate about the status of a criterion, definition, or even a request, as distinguished from the status of the item being abstracted, defined or requested, one needs this second attribute that can communicate status of the record or documentation of the Act (definition, order or criterion) as distinct from the Act.statusCode that reflects the state of the Act itself.

Change attribute Act.statusCode

  • isDocumentCharateristic: false

[ALL READERS: this was not discussed in Atlanta, but I believe it is a necessary step. Does it not "break" existing implementations??]

Add attribute criterionInd to Participation

Rationale

When defining criteria and definitions, it is necessary to be able to include all Participation types as part of the criteria, but the rules in document characteristics assign the isDocumentCharacteristic as true for selected participation type codes. The most notable example relates to the AUT type code where one would like to write criteria that include characteristics of the author. This new attribute when true will assert that this participation is part of a criterion or definition, and thus is not a document characteristic of the act in question.

Add attribute to Participation class

  • Name: criterionInd
  • Multiplicity: 0..1
  • Data Type: BL
  • Default Value: false
  • Definition:

    This attribute is intended for use in participations of Acts in CRT and DEF moods. It indicates whether or not the Participation is to be used as part of the characteristics of a criterion or definition. This value over-rides the isDocumentCharacteristic property asserted for the type code for this participation.

    Rationale: When defining criteria and definitions, it is necessary to be able to include all Participation types as part of the criteria, but the rules in document characteristics assign the isDocumentCharacteristic as true for selected participation type codes. The most notable example relates to the AUT type code where one would like to write criteria that include characteristics of the author. This new attribute when true will assert that this participation is part of a criterion or definition, and thus is not a document characteristic of the act in question.

Initial but Rejected Solution

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