Cardinality represents the minimum and maximum number of values that could exist inside a given element of an HL7 message. The HL7 messaging standard allows segments and fields, and sub-components in version 2.5, to be either optional or required and either singleton (non-repeating) or repeating.
Examples of HL7 message cardinality are shown in the following table.
Implementation of cardinality may vary between different healthcare applications. One application may implement cardinality exactly as the standard says. For example, one may allow zero to infinite patient addresses. Another application, however, may require one patient address and only allow one. The second application is not HL7 compliant, but this is a common decision made by development teams to fit their application’s data structures or other requirements with the HL7 standard.
| Field or Segment | Rule | Cardinality |
| Patient address field (PID-11) | optional and repeating | 0 to n |
| Patient primary language field (PID-15) | optional and non-repeating | 0 to 1 |
| Patient class field (PV1-2) | required and non-repeating | 1 to 1 |
| The Patient Identification (PID) segment in the Patient Admission message (ADT-A01) | required and non-repeating | 1 to 1 |
There are clinical healthcare systems that have misapplied cardinality rules and are not technically HL7 compliant. However, these systems are in use and are trading HL7 messages with other systems. This means that HL7 interfaces and interface engines must be flexible enough to handle these differences.
(2.50 out of 5)
Loading ...
.gif)
[...] Primarily this occurs in the areas of cardinality and the HL7 version that is used. Additional nonconformance occurs because of decisions made by development or implementation teams for the good of their system, or misinterpretations of the complex HL7 messaging standard. [...]
[...] this occurs in the areas of cardinality and the HL7 version that is used. Additional nonconformance occurs because of decisions made by [...]