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

Difference between revisions of "Message reshaping rules"

From HL7Wiki
Jump to navigation Jump to search
 
Line 17: Line 17:
 
'''Removal of fixed values'''
 
'''Removal of fixed values'''
  
Structural attributes
+
Attributes
  
 
If the value is listed as being fixed (=) then the attribute is not to be included in the flattened model.
 
If the value is listed as being fixed (=) then the attribute is not to be included in the flattened model.
  
Class attributes
 
  
For coded attributes, if a fixed value has been specified the attribute is not to be included in the flattened model.
+
'''Flattening'''
 +
 
 +
The fundamental algorithm (after stripping all fixed attributes) should be as follows:
 +
* Trace the tree down to its leaf classes (the deepest descendents along the association paths, ignoring recursive associations)
 +
** For each ‘leaf’ class, look up one level, decide if that association should be collapsed and the attributes of the current class should be collapsed into its parent
 +
*** If the class is marked as “do not collapse”, then don’t collapse it.
 +
*** If the ‘leaf’ class has no attributes or outgoing associations
 +
* if the association is 0..1, then treat the association as a boolean attribute (presence or absence of the class itself acts as an indicator)
 +
* otherwise drop the class entirely (it’s there to represent semantics, but doesn’t have any ‘business’ information)
 +
** If the class has only one attribute or association, then propagate that attribute or association up to the parent, adjusting cardinalities, conformance and mandatory as described below
 +
** If the class has more than one attribute and the association is 1..1 mandatory, propagate all the attributes up to the parent
 +
** Otherwise, collapsing cannot occur (the elements in the child class either repeat as a group or can be null as a group)
 +
** Repeat this process for the ‘parent’ class once all if its children have been processed.  Recurse until you’ve processed the root.
 +
 
 +
When collapsing:
 +
* minimum cardinality = minimum cardinality of existing element (attribute or association) * minimum cardinality of the association being collapsed
 +
* maximum cardinality =
 +
** If either the existing element (attribute or association) cardinality or the collapsing association cardinality is “*”, the resulting maximum cardinality is “*”
 +
** Otherwise, multiply the maximum cardinalities together
 +
* Mandatory =
 +
** If both the existing element and collapsing association are mandatory, collapsed element will be mandatory, otherwise it won’t
 +
** Conformance
 +
** If either the existing element or collapsing association are NP, the collapsed element is NP
 +
** Otherwise if the existing element or collapsing association are optional, the collapsed element is optional
 +
** Otherwise the collapsed element will be “R”
 +
 
 +
Note: InfrastructureRoot attributes, such as templateId and typeId are ignored here.  That may or may not be an issue.
 +
 
 +
There are some additional rules that deal with what happens to business names and annotations during the collapsing process, but we should first get agreement on the fundamental process.
 +
 
 +
'''Examples'''
 +
 
 +
Act --> ActRelationship --> Act
 +
RMIM:
 +
 
 +
 
 +
Original instance:
 +
<pre>
 +
<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
 +
<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
 +
<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="RSERV"/>
 +
<effectiveTime value="200310281511"/>
 +
<priorityCode code="1"/>
 +
<component1 typeCode="COMP">
 +
<specialty classCode="OBS" moodCode="EVN">
 +
<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="SPEC"/>
 +
<value codeSystem="2.16.840.1.113883.2.1.3.2.4.17.156" codeSystemName="Specialty" code="120"/>
 +
</specialty>
 +
</component1>
 +
</RequestService>
 +
</pre>
 +
 
 +
Reshaped instance:
 +
<pre>
 +
<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
 +
<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
 +
<effectiveTime value="200310281511"/>
 +
<priorityCode code="1"/>
 +
<component1.specialty.value codeSystem="2.16.840.1.113883.2.1.3.2.4.17.156" codeSystemName="Specialty" code="120"/>
 +
</RequestService>
 +
</pre>
  
'''Flattening'''
 
  
'''Act - ActRelationship - Act'''
+
Entity --> Role --> Participation --> Act
 +
RMIM:
  
When the Act is a leaf class and has two attributes or less (having removed fixed attributes) then the following shall happen:
 
*The Act shall be virtualized
 
*The child attributes shall have the Act name prepended to their name followed by a period eg. Observation.value.
 
*The child attributes shall then be inherited by the parent ActRelationship
 
When the ActRelationship has two or less attributes:
 
*The ActRelationship shall be virtualized
 
*The ActRelationship class name shall be prepended to the child attributes and the attributes of the entity followed by a period.
 
*All attributes shall be promoted to the parent Act
 
The parent Act will be flattened as the descendant of a parent Act – ActRelationship – Act relationship.
 
  
'''Entity - Role - Participation - Act'''
+
Original instance:
 +
<pre>
 +
<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
 +
<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
 +
<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="RSERV"/>
 +
<effectiveTime value="200310281511"/>
 +
<priorityCode code="1"/>
 +
<author typeCode="AUT">
 +
<AgentPersonSDS classCode="AGNT">
 +
<!-- SDS Role Profile ID -->
 +
<id root="1.2.826.0.1285.0.2.0.67" extension="7643324387"/>
 +
<agentPersonSDS classCode="PSN" determinerCode="INSTANCE">
 +
<id root="1.2.826.0.1285.0.2.0.65" extension="5452322"/>
 +
</agentPersonSDS>
 +
</AgentPersonSDS>
 +
</author>
 +
</RequestService>
 +
</pre>
  
Where the entity is a leaf class and there two attributes or less then the following shall happen:
+
Reshaped instance:
*The entity shall be virtualized
+
<pre>
*The Entity shall have the Role name prepended to its name followed by a period eg. performer.assignedEntity.
+
<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
*The child attributes shall then be inherited by the parent act
+
<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
If the role has less than two attributes then the following shall happen:
+
<effectiveTime value="200310281511"/>
*The role shall be virtualized
+
<priorityCode code="1"/>
*The role class name shall be prepended to the child attributes and the attributes of the entity followed by a period.
+
<author.id root="1.2.826.0.1285.0.2.0.67" extension="7643324387"/>
*All attributes shall be promoted to the parent participation
+
<author.agentPersonSDS.id root="1.2.826.0.1285.0.2.0.65" extension="5452322"/>
If the participation has got less than two attributes (after fixed values are removed) then the following shall happen:
+
</RequestService>
*The participation shall be virtualized.
+
</pre>
*The participation name shall be prepended to the child attributes
 
  
'''Entity - Role - Entity'''
 
  
Starting from the leaf entity the following rules shall be applied:
+
Entity --> Role --> Entity
 +
An example needs to be found for this.
  
If the Entity class has two attributes or less then the following shall happen:
 
*The Entity shall have the Role name prepended to its name followed by a period eg. performer.assignedEntity.
 
*The child attributes shall then be inherited by the parent act
 
Where the Role class has two attributes or less:
 
*The Role class will be virtualized
 
*The attributes will be promoted to the parent Entity
 
  
 
'''Issues:'''
 
'''Issues:'''

Revision as of 10:15, 15 June 2007

Message reshaping

This document is a proposal for the rules to reshape a message. It has been split into the two processes involved in reshaping, flattening and the removal of fixed values.

Conventions

When a class is removed from the serialization it is virtualized, this term will be used to describe this process from now on in this document.

This document will discuss the prepending of class names to attributes. When a message is sent it will actually be the association name that gets prepended.

The rules will not be applied when the class or association has been marked as not to be flattened.

Where a business name has been specified this will be used instead of prepending association names.

When a count of attributes is mentioned this will always be after attributes with fixed values have been removed according to the rules below. This doesn’t include attributes inherited from child associations.

Removal of fixed values

Attributes

If the value is listed as being fixed (=) then the attribute is not to be included in the flattened model.


Flattening

The fundamental algorithm (after stripping all fixed attributes) should be as follows:

  • Trace the tree down to its leaf classes (the deepest descendents along the association paths, ignoring recursive associations)
    • For each ‘leaf’ class, look up one level, decide if that association should be collapsed and the attributes of the current class should be collapsed into its parent
      • If the class is marked as “do not collapse”, then don’t collapse it.
      • If the ‘leaf’ class has no attributes or outgoing associations
  • if the association is 0..1, then treat the association as a boolean attribute (presence or absence of the class itself acts as an indicator)
  • otherwise drop the class entirely (it’s there to represent semantics, but doesn’t have any ‘business’ information)
    • If the class has only one attribute or association, then propagate that attribute or association up to the parent, adjusting cardinalities, conformance and mandatory as described below
    • If the class has more than one attribute and the association is 1..1 mandatory, propagate all the attributes up to the parent
    • Otherwise, collapsing cannot occur (the elements in the child class either repeat as a group or can be null as a group)
    • Repeat this process for the ‘parent’ class once all if its children have been processed. Recurse until you’ve processed the root.

When collapsing:

  • minimum cardinality = minimum cardinality of existing element (attribute or association) * minimum cardinality of the association being collapsed
  • maximum cardinality =
    • If either the existing element (attribute or association) cardinality or the collapsing association cardinality is “*”, the resulting maximum cardinality is “*”
    • Otherwise, multiply the maximum cardinalities together
  • Mandatory =
    • If both the existing element and collapsing association are mandatory, collapsed element will be mandatory, otherwise it won’t
    • Conformance
    • If either the existing element or collapsing association are NP, the collapsed element is NP
    • Otherwise if the existing element or collapsing association are optional, the collapsed element is optional
    • Otherwise the collapsed element will be “R”

Note: InfrastructureRoot attributes, such as templateId and typeId are ignored here. That may or may not be an issue.

There are some additional rules that deal with what happens to business names and annotations during the collapsing process, but we should first get agreement on the fundamental process.

Examples

Act --> ActRelationship --> Act RMIM:


Original instance:

<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
	<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
	<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="RSERV"/>
	<effectiveTime value="200310281511"/>
	<priorityCode code="1"/>
	<component1 typeCode="COMP">
		<specialty classCode="OBS" moodCode="EVN">
			<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="SPEC"/>
			<value codeSystem="2.16.840.1.113883.2.1.3.2.4.17.156" codeSystemName="Specialty" code="120"/>
		</specialty>
	</component1>
</RequestService>

Reshaped instance:

<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
	<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
	<effectiveTime value="200310281511"/>
	<priorityCode code="1"/>
	<component1.specialty.value codeSystem="2.16.840.1.113883.2.1.3.2.4.17.156" codeSystemName="Specialty" code="120"/>
</RequestService>


Entity --> Role --> Participation --> Act RMIM:


Original instance:

<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
	<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
	<code codeSystem="2.16.840.1.113883.2.1.3.2.4.17.140" code="RSERV"/>
	<effectiveTime value="200310281511"/>
	<priorityCode code="1"/>
	<author typeCode="AUT">
		<AgentPersonSDS classCode="AGNT">
			<!-- SDS Role Profile ID -->
			<id root="1.2.826.0.1285.0.2.0.67" extension="7643324387"/>
			<agentPersonSDS classCode="PSN" determinerCode="INSTANCE">
				<id root="1.2.826.0.1285.0.2.0.65" extension="5452322"/>
			</agentPersonSDS>
		</AgentPersonSDS>
	</author>
</RequestService>

Reshaped instance:

<RequestService classCode="PCPR" moodCode="EVN" xmlns="urn:hl7-org:v3">
	<id root="BBBBE23A-A9D1-A411-F824-9F7A00A33757"/>
	<effectiveTime value="200310281511"/>
	<priorityCode code="1"/>
	<author.id root="1.2.826.0.1285.0.2.0.67" extension="7643324387"/>
	<author.agentPersonSDS.id root="1.2.826.0.1285.0.2.0.65" extension="5452322"/>
</RequestService>


Entity --> Role --> Entity An example needs to be found for this.


Issues:

The repetition of names needs to be dealt with, e.g patient.patientPerson. Recommendation: A business name should be specified where repetition of names occurs.

Should flattening occur across model boundaries? Recommendation: flattening should occur across model boundaries unless specified in the referencing model that it shouldn’t occur for this model boundary.

Should a limit be set for the number of attributes that a class can contain in the algorithm?