Current Version - Under Revision
An application should provide a mechanism to allow users to specify retrieval requirements using SNOMED CT. This facility should allow queries to be generated that combine SNOMED CT specific selection criteria with other health record criteria.
Facilities for testing and traversing subtype relationships are essential for running most SNOMED CT queries that can be run against stored records. Additional functions that take account of the definitions of concepts and the refinements in expressions are needed to support more sophisticated retrieval.
Population-based retrieval and reporting is usually a task that can be run in the background or scheduled for later execution. Therefore, real - time responses are usually not essential.
The process of analyzing a large number of records may take several minutes or perhaps even hours. If the application spends a little time generating an optimized query before starting to access the records, this is acceptable and may shorten overall execution time. Therefore, a technique such as query expansion may be appropriate for these tasks.
Users may also have requirements for reports on individual patients or a small group of patients. In some cases there may be an expectation of a real - time response to requests for these reports. If so, the delay while several selection criteria are expanded may be unacceptable. If the same criteria are used many times, storage of the expanded form may be a realistic option. Otherwise, an alternative retrieval technique should be considered.
Decision support tools are usually used during a consultation with a patient. Real - time response without significant delay is essential if these tools are to be used regularly and perceived as a help rather than a hindrance. A decision support algorithm may need to selectively retrieve several records to inform a single decision or piece of advice. Many of the retrieval criteria are likely to be quite general. The time taken to expand an apparently simple set of criteria so that they include all appropriate subtypes is likely to significantly impair performance. The expanded criteria could be stored in or associated with the protocol. However, the requirement to update these with new SNOMED CT releases and whenever the protocol changes add to the maintenance burden.
Since decision support protocols are primarily concerned with the records of an individual patient, it may be feasible to test all candidate records (e.g. all records that fall within a specified date range) to see if any of these are subtypes of the selection Concept (s).
Other alternatives should also be considered.
As well as retrieving SNOMED CT encoded information a decision support tool may need to make entries in the record. These entries may arise directly from user interaction with a template or protocol. However, some entries made by decision support tools may record decisions made by or advice given by the tool.
Records that have been encoded using Concepts that are no longer active can be retrieved by using the Historical Associations Reference Set values (i.e. "same as," "may be a," 370124000 |replaced by| and "was a") in addition to 116680003 |is a| subtype relationships .
An application should allow users to specify which (if any) of these Relationships or Associations should be followed when determining whether to retrieve a record entry.
SNOMED CT can also be used for generated queries that examine legacy data recorded using SNOMED International, Clinical Terms Version 3 or earlier versions of the Read Codes. This can be done by using the approach outlined in strategies for data migration, to generate a query that includes all the subtypes of a selection Concept. However, the appropriate legacy codes (i.e. Read Codes, CTV3IDs or legacy SNOMED codes) are added to the query instead of the Concept Identifier .