The Logical View shows the resources as a tree structure with the following columns:
TBD (01510): Needs Verification. Up to then the information from segments is taken.
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. |
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
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.
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.
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.
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".