SNOMED Documentation Search


 Other Documents
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

To avoid any confusion and misinterpretation it is important that the input data is represented in a way that ease the interpretation of the input data and ensure correct processing of the expression template. Poorly represented input data may result in expressions that express a different meaning than intended, which can be critical if the resulting expressions are used for safety critical purposes (storage, communication, trigger decision support rules etc.)

Templates with Repeatability of Groups and Attributes

In situations where the template allow for attribute-value pairs or relationships groups to be repeated, the input data should be explicit about 

The data used to populate this could be represented explicit like this:


 

 

The above input data would result in following four expressions to be generated when processing the template:


Templates with Cardinality Constraints

Specifying the expression and group when representing input data is particularly important when the template includes cardinality constraints, to be able to determine the repeatability of groups and attributes. Expression templates which specifies a [1..1] cardinality of slots or expression parts can omit the group column, as shown in the following example.  

Cardinality Constraints on Groups

Consider the following template, where the template includes a cardinality constraint on the group like this:

[[@Expression ]]  64572001 |Disease|  : [[1..*]] 
[[1..1 @Group]]{ 
363698007 |Finding site|   =  [[+ (<<  272673000 |Bone structure|  ) @Site]],
   
116676008 |Associated morphology|   =  [[+ (<<  72704001 |Fracture|  ) @Morphology]] }
In this situation, processing the template against the input data  would result in a processing error, because the first expression would not be valid. the expression template allow for only one @Group within each expression, whereas the input data specify an expression with more that one @Group. 


 

 

So in this case, there would be no need to include the second column in the input data to differentiate between different groups in the same expression. Hence, the input data could be simplified as:

Cardinality Constraints on Attributes


Consider the following template, where the template includes a cardinality constraint on each attribute like this:

 

[[@Expression ]]  64572001 |Disease|  : [[1..*]] 
[[1..1 @Group]]{ [1..1] 
363698007 |Finding site|   =  [[+ (<<  272673000 |Bone structure|  ) @Site]],
  [1..1] 
116676008 |Associated morphology|   =  [[+ (<<  72704001 |Fracture|  ) @Morphology]] }

 

In this case,  the second expression would not be valid … so there would be no need to include the expression column, as each row would signify a separate expression. That is, we could just define the data as: 

 


Similarly, if only precoordinated concepts were allowed in the slots, like this:

 

[[@Expression ]]  64572001 |Disease|  : [[1..*]] 
[[1..1 @Group]]{ [1..1] 
363698007 |Finding site|   =  [[+ id(<<  272673000 |Bone structure|  ) @Site]],
  [1..1] 
116676008 |Associated morphology|   =  [[+id (<<  72704001 |Fracture|  ) @Morphology]] }
 


then only the following data value would be valid:

 

Summary

In summary, it is recommended to be as explicit as possible when specifying input data for expression templates. However, in situations the input data can be simplified, and then following default can be  assumed by the input data:

  • if the expression column is omitted then it is assumed that each row should be processed into separate expressions (i.e. no repeating of rows into the same expression)
  • if the grouping is omitted, then it can be assumed that each column should be processed into separate expression parts (i.e. no grouping of rows into the same expression)

 

 


Feedback
  • No labels