visit the hl7 website The Demo site for our new HL7 Version 2+ (plus) Standard

16.3 Message Structures (99.2)

16.3.1 List of Message Structures (99.2.1)

16.6.31 Explanation (99.2.2)

TBD (01510): Needs Verification. Up to then the information from segments is taken.

The Logical View shows the resources as a tree structure with the following columns:

Column

Content

Segment

The code for a segment or the name of a segment group.

Cardinality

The minimum and maximum Cardinality for repeating this segment or group, if constrained to less than [0..*].

MustImplement

The application must implement (support) an element marked as "yes".

Status

Additional Information about the current status of this element.
The most frequent indication is "deprecated", i.e. the element is contained only for backward compatibility with the intent not to use it anymore.

Comment

Additional comments that the steward groups feels worth to mention.

 

Here is an example:

TBD (01563): Example for message structure

Segment Cardinality Must Support Status
ADT^A03^ADT_A03
MSH 1..1 Yes
PROCEDURE  
PR1 1..1 Yes
PDA 0..1  

 

Key to Type Icons and Flags

16.6.32 Mapping and Compatibility with former v2.x standard (99.2.2)

The following table helps to understand, how previous version of HL7 v2.x is converted into v2+.

The most important topic is to align the technical terminology that is used to write and publish the specification, namely:

Some terms like "R" and "RE" are still under discussion. Therefore the following changes are intended:

Optionality/usage resp. the corresponding AMS constructs are replaced by a "must-support" flag, that allows for the following values: "yes", "no" and "empty". "empty" is the default and can be constrained to either "yes" or "no", but once constrained cannot be changed any more in derived profiles /specialisations.

Repetitions resp. the corresponding AMS constructs are replaced by cardinality. Here the following constraints are intended: "min..max", where min starts with "0" and max="*". min is increased, max is decreased until they are equal.

16.6.32.1 for Fields (99.2.2.1)

Optionality

Repetition

=>

Must Implement

Cardinality

Comment

R

yes

min = 1

RE

yes

min = 0

O

fully open

X

no

min = 0, max = 0

B

represented as a comment

W

represented as a comment

C(a/b)

that depends on the evaluation of "a" and "b", but can be translated into must-support and cardinality

n

max = n

*

max = *

Combinations are combined accordingly.

16.6.32.2 for Message Structures (99.2.2.2)

AMS

=>

must Implement

Cardinality

[ { } ]

0 .. *

[ ]

0 .. 1

{ }

1 .. *

< empty >

yes

1 .. 1

marked as withdrawn

no

0 .. 0

Opening parenthesis are used to introduce groups of segments.

16.6.32.3 Must-Implement (99.2.2.3)

An important point is the definition of must-support. Even if the intend is to come as close as possible to use the same technical terminology like with FHIR, some definitions cannot be provided as free as with FHIR. FHIR does not provide any base requirements. This is left for profiles that also individually declares what "must-support" mean. For v2+ the definition for must-support is equal to the previous definition of "RE".