Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

The previous section deals with the retrieval of records that contain precoordinated representations of Concepts. The mechanisms and methods discussed in that section need to be extended to cover postcoordinated expressions .

The selective retrieval mechanisms applicable to postcoordinated expressions depend on the way in which this data is stored. If data is transformed to generate tables or indices that facilitate retrieval, the form of this derived data determines the type of mechanisms that can be used.

There are two significant factors in the completeness, specificity and performance:

Retrieval from unrestricted relational representations of postcoordinated data

Unrestricted relational representations provide a flexible medium for storage retrieval of postcoordinated expressions. A query can be specified at any level of detail to examine the primary Concept in a statement and any or all of the associated postcoordinated qualifications, modifications, or combinations.

However, the number of joins required to specify an appropriate query may affect performance.

  • Each clinical statement consists of a row in one table joined to a row in a qualifier table for each postcoordinated refinement. The clinical statement itself may have other structural relations (based on the record structure) and each patient record may consist of hundreds of thousands of statements.

The effect of this will vary according to the power and configuration of the relational database. However, some application developers may seek alternative, more limited representations to improve performance.

Retrieval from restricted postcoordinated information

An application may store data in a restricted relational representation, which limits postcoordination to a pre-specified set of qualifiers. Criteria for selection based on the values of a limited set of qualifiers require a minor extension to any of the approaches discussed in the previous section. However, there are two significant points to note:

  • When applying criteria to the values of a qualifier, any subtype of the specified value should be selected. This is similar to the consideration for the primary Concept. However, the number of tests to be performed will be more limited because:
    • Typically a qualifier value will have relatively few subtypes ;
    • Only record entries that match on other criteria need to be tested.
  • Some of the supported qualifying attributes may also occur in defining characteristics of some Concepts. A query that specifies the presence of a particular qualifier must not miss these cases. One way to address this issue is to ensure that when storing or transforming data for retrieval, the value of any defining characteristics that are also supported, and qualifying attributes should be copied into the qualifying value field.

Retrieval from postcoordinated data stored as parsable text or XML

Parsable text String or XML elements are not well suited to rapid retrieval from large populations of records. However, optimization is possible by augmenting the stored form with indexes to Concepts (e.g. indexing Concept Identifiers or range number) or by using an XML-aware database. Without such optimization it may be possible to achieve acceptable performance for retrieval from individual records, documents or messages represented in a structured form using XML.

Retrieval of postcoordinated data stored as entered

Where postcoordinated data is only stored as entered, retrieval mechanism must do all the hard work of calculating the equivalence between statements expressed in different ways. This is possible for a small-scale search (e.g. within a single patient record) but across a large population of records it may be difficult to achieve an acceptable performance.

Retrieval from minimized postcoordinated forms

If postcoordination is minimized before storage, this allows most of the search process to be concerned with querying or testing subtype descendants .

If the query needs to specify selection criteria that cannot be expressed by a single Concept, further testing is required. Even then, if there are rules for consistently minimizing postcoordination , most queries remain easy to construct and apply.

Some complex queries may present more difficulties with this approach but it remains a reasonable option for application developers concerned with minimizing the overhead related to storage and retrieval while delivering reasonable performance and flexibility.

Retrieval from maximized precoordinated forms

Maximization of postcoordination offers them most flexible approach. Of the three forms suggested:

  • The exhaustive form:
    • Simplifies queries since everything that is true about a Concept is stated and there is no need to check subtype descents;
    • Carries a heavy storage penalty for every record stored;
    • Requires computation of the representation of each Concept after every release.
  • The long canonical form:
  • The short canonical form:
    • Requires slightly more care in construction of queries than the long canonical form ;
    • Requires slightly less storage than the other maximized forms;
    • Like the long canonical form , can be rebuilt directly from the release tables.