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

Difference between revisions of "Context Conduction - Act Attribute Conduction"

From HL7Wiki
Jump to navigation Jump to search
 
Line 1: Line 1:
{{MnM Open Hot Topic}}
+
{{MnM Closed Hot Topic}}
  
  
Line 21: Line 21:
 
**I find act attribute conduction is not intuitive both to end users and tooling, and it will add more complexity to the implementation in the future if it is being adopted.
 
**I find act attribute conduction is not intuitive both to end users and tooling, and it will add more complexity to the implementation in the future if it is being adopted.
 
**I think we should only specify what are the attributes in Act conductible at the most, e.g we specify confidentialityCode is conductible. If there is a need to override it at certain acts, then just override the value explicitly.You may argue that it may not be completely in line with the approach for participation and actRelationship conduction, however I would argue that this slight deviation will make the modeling and implementation easier and more intuitive though at certain extent the data may be repeated.
 
**I think we should only specify what are the attributes in Act conductible at the most, e.g we specify confidentialityCode is conductible. If there is a need to override it at certain acts, then just override the value explicitly.You may argue that it may not be completely in line with the approach for participation and actRelationship conduction, however I would argue that this slight deviation will make the modeling and implementation easier and more intuitive though at certain extent the data may be repeated.
 +
 +
===Resolution===
 +
The necessary changes have been made in the RIM (Nov. 2010) and are documented in the Core Principles document.

Latest revision as of 17:58, 15 May 2011


Overview

Some attributes such as languageCode and confidentialityCode have propagation like behaviors. However, no rules are yet defined for them. CDA R2 identified a couple of act attributes that were part of the context of a CDA document, and effectively conducted from the header to the body of a CDA R2 document. This was a convention adopted in a V3 standard that has no basis for support in the RIM today. This is a proposal to put in place a mechanism for conducting certain act attributes from one act to another. It follows the approach recently added for conducting act relationships and participations.

CDA R2 also needs to be a ble to block these attributes from conducting in some circumstances. The use case for blocking conduction of these is clear in the CDA context, and I'll add that use case to the document. In the case where the document has an act relationship to a parent document you certainly don't want the context (attribute level or otherwise) conducting from the current document to the parent document, which has its own context including language and confidentiality, so that conduction needs to be blocked in the act relationship associating the two. An alternate use case is where a CDA section has a different language than that indicated in the header. In that case, according to this proposal, you need to block conduction of language to that section so you can assert a different language for the section.

Proposed Approach

Follwoing the latest apporach for context conduction

  • Add a new attribute to act relationship called actAttributeContextBlockedCode
  • Add a boolean nproperty to act attributes called "conductible"
  • make all act attributes conductible attribute false except for languageCode and confidentialityCode which would be set to true
    • the actual list of conductible attributes will need to be carefully reviewed.
  • create a new coding system containing codes for the conductible act attributes
  • bind the new code system to the new actAttributeContextBlockedCode property
  • to block all attribute conduction add a code to the new coding system that is the parent of all these conductible attribute codes

Alternative

  • Victor Chai
    • I find act attribute conduction is not intuitive both to end users and tooling, and it will add more complexity to the implementation in the future if it is being adopted.
    • I think we should only specify what are the attributes in Act conductible at the most, e.g we specify confidentialityCode is conductible. If there is a need to override it at certain acts, then just override the value explicitly.You may argue that it may not be completely in line with the approach for participation and actRelationship conduction, however I would argue that this slight deviation will make the modeling and implementation easier and more intuitive though at certain extent the data may be repeated.

Resolution

The necessary changes have been made in the RIM (Nov. 2010) and are documented in the Core Principles document.