Current Version - Under Revision
Various media exist for communicating computer processable data between applications. These include:
- Structured documents;
- Portable storage media (smart cards, memory cards or other similar devices);
- Application interfaces (including COM / CORBA and programmable web interfaces).
A common feature of any method of communication is the need for a formal standard (or de-facto agreed) representation of the communicated information.
Some current standards do not provide explicit support for postcoordination . Examples include:
- HL7 Version 2.x messages;
- EDIFACT implementations of European ( CEN) Prestandards for laboratory communication used in by the UK NHS .
In these cases, it may still be possible to include postcoordinated information by agreeing to a syntactic representation that can be used in a single message element.
The use of this type of technique is not recommended since it may distort the intended semantics of the message, but also, and more significantly, it requires the recipient to agree to parse the code in a particular way. There is no point sending a parsable text representation of a postcoordinated Concept to recipients with no understanding of that form of representation.
More recent standards make specific provision for the support of postcoordination in representations of clinical statements. Examples include:
- HL7 Version 3, which includes the " concept description " (CD) data type which provides unlimited scope for postcoordinated modifiers;
- European ( CEN) Prestandard ENV13606 for Electronic Healthcare Record Communication, which include a component name structure element, which permits postcoordination .
Communication of SNOMED CT data using explicit structures for postcoordination is strongly recommended. However, where local agreements permit, other solutions may be used. This is discussed further in the next section.