CHANGE PROPOSAL: LOINC table STATUS field

Regenstrief is seeking feedback on a planned change to the concept “STATUS” field in the LOINC table that could be implemented in the next release (v2.31, June 2010).



Presently, this field is Null for all active terms and populated with “DEL” for terms that are deprecated or superseded. The need to accommodate and accurately identify a more finely tuned set of concept states has become apparent in several recent uses cases. We have reviewed the possible concept status values in other terminological systems and considered the LOINC use cases, and now propose supporting the following values for concept status, with the definition and implications for use listed here:


    ACTIVE: Concept is active. Use at will.

    TRIAL: Concept is experimental in nature. Use with caution as it may change.

    DISCOURAGED: Concept is not recommended for current use. New mappings to this concept are discouraged, but existing mappings may still remain valid.

    DEPRECATED: Concept is deprecated. Concept should not be used, but is retained in LOINC for historical purposes. The superseding concept is indicated wherever possible in the MAP_TO field.


In addition, we will add two new fields: STATUS_REASON and STATUS_TEXT. At present, STATUS_REASON would be null or in cases where the deprecation reason is clear we would indicate it as: AMBIGUOUS, DUPLICATE, or ERRONEOUS. The STATUS_TEXT field would be optionally populated with explanatory text.

At first implementation we would populate STATUS with "ACTIVE" or "DEPRECATED" for all terms based on their existing status. We will also build functionality in RELMA to accommodate the new values.

As an example of the need for a "TRIAL" status is illustrated in our work with creating a LOINC representation the federally required patient assessment instruments. In this case, the item meaning is defined in the context of use within that instrument. We have been fortunate to work with assessment developers in the early stages of instrument development. This is advantageous because it enables the codes to be included in data specifications and documents as they are developed, but we are in the position of creating codes and names for data elements whose definitions are presently in flux...though they will be settled ultimately by an authoritative body (CMS). These items are only intended for one purpose - the final release of the CMS content. Such a category would allow us to release codes in our public distribution but users would be clued to their 'pending' status.

We would like to hear comments from the LOINC user community in support of or against this proposal. Please send comments to:

loinc@regenstrief.org

Pending any major negative comments, we are prepared to implement this change in the June 2010 (v2.31) release