Message reshaping rules

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?