This wiki has undergone a migration to Confluence found Here
Difference between revisions of "V2 Lengths"
Jump to navigation
Jump to search
(Placeholder) |
|||
| Line 1: | Line 1: | ||
| − | + | = Background = | |
| + | |||
| + | * long controversy concerning lengths | ||
| + | * lack of clarity concerning what we are trying to do | ||
| + | * problem of the back door | ||
| + | |||
| + | = Solution = | ||
| + | |||
| + | # stop reporting lengths on complex types | ||
| + | ** value is increasingly difficult to determine | ||
| + | ** value is specific to vertical bar representation | ||
| + | ** value is useless and misleading | ||
| + | ** only define lengths for primitive types (ST etc) | ||
| + | ** only report lengths were the context of use has different rules to definition of type | ||
| + | |||
| + | # differentiate between authoritative lengths and arbitrary lengths | ||
| + | * some lengths are authoritative | ||
| + | *** codes fixed by HL7 | ||
| + | *** segment/field references | ||
| + | *** realm fixed value in a realm specific message | ||
| + | ** authoritative lengths are fixed and normative - may not be violated | ||
| + | ** systems must support valid data that they encounter | ||
| + | * some lengths are arbitrary - any particular length is wrong | ||
| + | *** lengths of codes and names, address parts | ||
| + | ** Do not make normative rules. But some length guidance is still useful | ||
| + | ** so provide a "conformance length": the minimum length that must be supported | ||
| + | ** conformance length offers a degree of predictability without preventing real world problems being solved | ||
| + | |||
| + | # add support for truncation pattern | ||
| + | ** truncation behaviour exists in the wild | ||
| + | ** it works better if systems are able to communicate about truncation | ||
| + | ** truncation allows this. | ||
| + | ** truncation pattern is not required | ||
| + | ** some content (identification, clinical descriptions) are not allowed to be truncated | ||
| + | ** some data type specific truncation rules (numbers, dates) | ||
Revision as of 12:45, 4 August 2008
Background
- long controversy concerning lengths
- lack of clarity concerning what we are trying to do
- problem of the back door
Solution
- stop reporting lengths on complex types
- value is increasingly difficult to determine
- value is specific to vertical bar representation
- value is useless and misleading
- only define lengths for primitive types (ST etc)
- only report lengths were the context of use has different rules to definition of type
- differentiate between authoritative lengths and arbitrary lengths
- some lengths are authoritative
- codes fixed by HL7
- segment/field references
- realm fixed value in a realm specific message
- authoritative lengths are fixed and normative - may not be violated
- systems must support valid data that they encounter
- some lengths are arbitrary - any particular length is wrong
- lengths of codes and names, address parts
- Do not make normative rules. But some length guidance is still useful
- so provide a "conformance length": the minimum length that must be supported
- conformance length offers a degree of predictability without preventing real world problems being solved
- add support for truncation pattern
- truncation behaviour exists in the wild
- it works better if systems are able to communicate about truncation
- truncation allows this.
- truncation pattern is not required
- some content (identification, clinical descriptions) are not allowed to be truncated
- some data type specific truncation rules (numbers, dates)
