Storing Clinical Records with SNOMED CT

Storing SNOMED CT encoded clinical records involves the storage of:

• Codes: Concept codes (SNOMED CT Identifiers for concept)
• Terms: User-selected terms (which may be SNOMED CT terms)

In some implementations of SNOMED CT this may also involve the storage of:

• Expressions composed of multiple codes
• Identifiers for expressions which are held in an Expression Library

Clinical data which is stored using SNOMED CT will use SNOMED CT concept identifiers. SNOMED CT Identifiers are represented as a string consisting of between 6 and 18 digits. Further detail can be found in the Technical Implementation Guide: http://snomed.org/tig.
In most cases, the term selected by the user is also stored. The structural representation of stored clinical information is important. This must store similar information consistently, and the storage design must support effective querying.

Binding and Mapping to SNOMED CT

User interfaces commonly restrict the data that can be selected by the user and stored. Electronic messages are also often constrained in terms of the permissible values that may be meaningfully included in each field. Decisions are made on whether some semantics, such as the priority for a procedure, is expressed in a reserved part of the message structure, or if it is expressed as part of the SNOMED CT expression within the message.
As part of implementation there may be a need to either:

• Bind SNOMED CT to relevant parts of the design, and/or
• Create and use a map between a pre-existing terminology and SNOMED CT

The implementer should balance the cost of developing and maintaining an inter-terminology map, with their target quality for that map. Unless an existing terminology scheme represents clinical ideas in a comparable way to SNOMED CT then a perfect (i.e. lossless and reversible) map may not be possible.

Data Entry with SNOMED CT

Existing data entry interfaces may be modified to incorporate SNOMED CT in the required places, often as a direct replacement of another coding scheme.
Data entry features which may be enhanced or enabled using SNOMED CT include:

• Search and entry of single codes
  • Optimized design of a search tool for effective use with SNOMED CT is addressed in the Search and Data Entry Guide. This is currently available under Public Draft Documentation in the SNOMED CT Document Library at http://snomed.org/doc.
• Clinical data entry interfaces comprising numerous data items, including selection from short pick lists, and selectable singe items (check boxes).
  • Data entry interfaces have discrete items or lists of items from SNOMED CT 'bound' to a field. An example would be the binding of a single SNOMED CT Concept to a checkbox, so that when checked the SNOMED CT Identifier for the concept is stored in the clinical record.
  • Pick list can be configured by 'binding' to a SNOMED CT subset, or by enumerating the members of the pick list within the interface design.
• The encoding of free text data entry using SNOMED CT, for validation by a user
  • Using Natural Language Processing tools which work with SNOMED CT
• The use of images as a way of selecting coded entries e.g. anatomical images
  • This is a variation in which SNOMED CT is bound to regions of an image, rather than a coded or text based field

Attention is needed to identify which parts of the data entry interface are both in scope of SNOMED CT and which the implementer intends to be encoded using SNOMED CT. For example, when implementing a scored assessment with many questions, an implementer may choose to encode only the assessment result with SNOMED CT.
SNOMED CT allows a level of precision of meaning that is rarely matched by the content of proprietary terminology systems. For this and other reasons, there may need to be modifications or enhancements to the user interface and how it allows users to search, enter and express clinical ideas.

Maintaining SNOMED CT Enabled Products

Routine scheduled maintenance of EHRs is anticipated and supported by SNOMED CT, which also has a program of continuous improvement. Unlike some classification or coding schemes, SNOMED CT updates, adds and inactivates content where it is useful to do so.
The changes to SNOMED CT content include changes to the status of a concept or term e.g. from active to inactive. Relationships between concepts change for a variety of reasons, including the refinement of a concept definition, in response to new medical understanding, or the introduction of new concepts.
The most common activities relating to changes to SNOMED CT content are:

• Substituting a prior version of a subset with its more recent version, for example, in a data entry interface
• Substituting an inactivated Concept with a suitable nominated replacement
• Substituting an inactivated Term with a suitable alternative
• Evaluating the impact to an existing subset
• Updating of bindings and SNOMED CT queries

Messaging with SNOMED CT

Implementation of SNOMED CT within a system is not always concurrent to the adjustment of external electronic clinical data flows. The design of the electronic message, and the definition of the data extract which is used to populate the message, may need to be modified to accommodate its SNOMED CT payload. Similarly to data storage, an electronic message may require the inclusion of:

• Codes: Concept codes (SNOMED CT Identifiers for concepts)
• Terms: User-selected terms (which may be SNOMED CT terms)

For a more extensive use of the features of SNOMED CT, messages may include:

• Expressions composed of multiple codes
• Identifiers for expressions which are held in an Expression Library

Migrating Clinical Records between Systems

Some implementation strategies include the bulk migration of data between different versions of their system or between different systems. In this or similar circumstances, the tasks of data Extraction, Transformation and subsequent Loading ['ETL'] are performed.
Data migration can include the use of:

• Maps between items from the existing terminology to the SNOMED CT equivalent
• Transformation of data between the different physical data structures (or the more abstract 'information models') of the source and the target system

SNOMED CT supports multiple different ways for a concept to be expressed and stored. A concept may also have some parts of its meaning expressed within the data structure itself. For example, some of the different ways in which SNOMED CT can be used to represent a 'family history of' a disorder include:

• As a single SNOMED CT coded item
• As a SNOMED CT expression comprising two or more SNOMED CT concepts, one of which gives the context of Family History
• By representing the 'family history' via a dedicated table within the storage schema reserved for family history records, and populating this with the SNOMED CT Concept for the relevant disorder

Reporting with SNOMED CT

System outputs such as mandatory reports need to be supported at each implementation stage.
Reports can be used to guide resource allocation, for reimbursement, or for clinical quality evaluation, so the ability to provide these reports before and after any systems change is important to customers. Beyond the initial task of replicating existing reports and results, the analysis power of SNOMED CT can be exploited to generate new reports or types perhaps not previously possible.
IHTSDO distributes a map from SNOMED CT to ICD-10. This supports the generation of ICD-10 classified data from data originally recorded using SNOMED CT, or later mapped to SNOMED CT.
Transition to the use of SNOMED CT for clinical records will require, in some cases, re-development of the data processing to populate the reports. However, in many cases SNOMED CT will enhance previous reporting capabilities.