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:
- postcoordinated expressions ; The structure used for representing
- Whether the information is only stored in the form entered of is also stored in a manner that seeks to facilitate efficient and consistent retrieval of postcoordinated expressions .
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:
- 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 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:
- The long
- Allows queries that are relatively simple provided that a mechanism exists for checking subtype descents.
- Although more terse than the exhaustive approach, storing this information for every record stored still has a significant storage overhead.
- Requires rechecking or re-computing after a release, but his can be done directly from the release files by combining the 116680003 |is a| relationships in the Canonical Table with the other (i.e. not " 116680003 |is a| ") defining characteristics in the Relationship file .
- The short canonical form: