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

Discussion of types in RIM document

From HL7Wiki
Jump to navigation Jump to search

Editing of harmonization proposals prior to a harmonization meeting is restricted to the proposal submitter and the co-chairs of the steward comittee. Other changes will be undone. Please add comments to the "discussion" page associated with this proposal.

Recommendation for HL7 RIM Change RECOMMENDATION ID:
Sponsored by: Technical Committee name Approval date by committee:
Revision (# and date): Date submitted: 16 Oct 2006
Editor/Author: Charlie McCay  
PROPOSALNAME: Description of types  

Stewards Position

REQUIRED - This table should contain one row for each Steward Committee affected by the recommendation.

(responsibility level: S=Steward; I=Interested)
Comittee1 Unknown/Reviewed/Approved S or I
Comittee2 Unknown/Reviewed/Approved S or I


Description of relationship between DATAVALUE.type, typeId, templateId, profileId, interactionId is missing. Also the definition of profileI and InteractionId implies that these only convey the constraints on the information to be conveyed -- whereas they also imply sendre and receiver responsibilities -- this inconsistency should be addressed.


It is recomended that the text for

RIM Recommendation(s)

Add a paragraph discussing the relationship between the attributes into the definition of typeId, and reference it from the other sections.

Vocabulary Recommendation(s)



There is a need for greater clarity

Recommended Action Items

  • Implement the proposed solution


The following are the existing definitions taken from the 2006 normative editation Message.profileId:: LIST<II> (0..*) Definition:The message profile identifier allows a given implementation to explicitly state how it varies from the standard message definition.

When multiple profiles are specified, the message instance must be valid against all of them. However, a receiver may choose to validate against only the first one recognized. For this reason, 'preferred' or more-rigorous profiles should be listed first. Transmission.interactionId:: II (0..1) Definition:The interaction identifier is a reference to the unique information interchange derived from the V3 MDF for specifying a message.

Note: This attribute is also present in the sibling class, Batch. This change was made rather than moving this attribute to their common ancestor class, Transmission. This decision was taken because we do not have all the methodology and backwards compatibility issues worked out. Once we have established our backwards compatibility, we should promote this attribute to the parent. The problem is the sequencing of attributes within the HDF and their impact on the ITSs. InfrastructureRoot.typeId:: II (0..1) Definition:When valued in an instance, this attribute signals the imposition of constraints defined in an HL7-specified message type. This might be a common type (also known as CMET in the messaging communication environment), or content included within a wrapper. The value of this attribute provides a unique identifier for the type in question. InfrastructureRoot.templateId:: LIST<II> (0..*)

Definition:When valued in an instance, this attribute signals the imposition of a set of template-defined constraints. The value of this attribute provides a unique identifier for the templates in question.

1.11.1 Data Type : TYPE

Definition: Represents the fact that every data value implicitly carries information about its own data type. Thus, given a data value one can inquire about its data type.

invariant(ANY x) {




NOTE: This template puts this proposal in the "Harmonization Proposal" Wiki Category. Once the proposal has been discussed and the resolution has been aded, please update the Category statement to put the proposal in the "Discussed Harmonization Proposal". The "Harmonization Proposal" Wiki Category is for OPEN non-discussed proposals only.