SNOMED Documentation Search
The diverse nature of EHR systems, as well as the wide scope of SNOMED CT, means that there can be no universal approach. There are different ways to achieve similar outcomes and variation between the development sequences taken to reach the same outcome.
Implementation strategy and planning is discussed here by addressing:
The simplified depiction of an EHR system shown in Figure 5 is used to illustrate a variety of alternative configurations in which SNOMED CT is implemented in one of more of the component parts of an EHR.
Figure 5. Schematic illustration of an EHR system
The illustration above shows as separate components the user interface, data storage and external data communication, for systems interoperation. In the SNOMED CT documentation these are considered collectively to be part of a Clinical Records implementation. Other types of implementation include linking to Knowledge Resources and Aggregation and Analysis. These are illustrated above by the Knowledge Resources and Reporting and Analytics components. In the diagram, a distinction is made between Reference Data such as SNOMED CT or ICD-10, and the clinical data records held in the clinical data store. Separate from both of these is the Analysis Data Store in which copies of parts of the collection of clinical data records are held separately in support of data analysis and reporting.
One way of categorizing the components illustrated above is:
The diagrammatic conventions used in this section are shown in Figure 6 below
Figure 6. Color key for Figure 7 to Figure 16 inclusive
The rest of the section introduces ten ways in which SNOMED CT can be used in EHR systems. As mentioned earlier, these are not exhaustive or even fully mutually exclusive, but just illustrative. Ten approaches of using SNOMED CT are:
Based on the categorization introduced earlier about clinician use or use by others, approaches 1, 2, 4, 5, 8, 9 and 10 are primarily aimed at clinician use, whereas approaches 3, 6 and 7 are primarily aimed at use by others. However approaches 6 and 7 include elements of interest to clinicians, and approaches 9 and 10 include elements of interest to others.
Figure 7. SNOMED CT as a Reference Terminology for Communication
This approach uses SNOMED CT as a 'Reference Terminology', mapping clinical record data to SNOMED CT for inbound and outbound communications with other systems. Where there is a need to exchange SNOMED CT encoded clinical data with other systems, this approach has merit. For an EHR system without any pre-existing SNOMED CT implementation, this approach is likely to have lower costs for re-engineering than other options; however it does not offer any benefits apart from enhanced data exchange. The transformation to and from SNOMED CT will need to be maintained over time and the mapping may result in some information loss.
Figure 8. SNOMED CT as a Reference Terminology for Data Integration
This approach uses SNOMED CT as a 'Reference Terminology' for data integration, by transforming the various codes and free text received from external systems into SNOMED CT. This approach will usually be combined with one of the following approaches that uses the integrated data for reporting, querying, decision support, or displaying to the user in a consistent way.
Figure 9. SNOMED CT as an Indexing System for Data Retrieval
This approach has benefits for those who perform data analysis as well as for front-line clinical users. It features no change to data entry or the principal clinical data storage. Records stored as narrative text or using other code systems are processed by a routine that matches the stored codes (and/or narrative text) to appropriate precoordinated SNOMED CT concepts. The end result is a representation of relevant parts of the record information tagged and indexed using SNOMED CT. The resulting index is then used by the Reporting and Analytics subsystem to support querying, retrieval and analysis using terminology based on SNOMED CT.
Figure 10. SNOMED CT as a Code System for Clinical Data in the EHR
An implementer who is motivated to introduce SNOMED CT records, but who is also keen to keep changes to the clinical user experience to an absolute minimum, may choose this approach. It can be a low risk step towards a more extensive use of SNOMED CT. The quality of the map between the 'retained interface terminology' and precoordinated SNOMED CT concepts will need to meet a variety clinical governance requirements, as set locally. As the data store content uses SNOMED CT, SNOMED CT concept codes are available for communicating with external systems. An approach of this type is likely to be recognized as 'storing and exchanging records using SNOMED CT'.
Figure 11. SNOMED CT as an Interface Terminology for EHR data entry
Employing SNOMED CT at the user interface is the distinction of this approach from the preceding one. It removes the complexity of creating and maintaining a map from the interface terminology to SNOMED CT. Given the large number of terms available in SNOMED CT, this approach may be supported by the use of SNOMED CT subsets to constrain the search for the appropriate SNOMED CT concept. As the data store content uses SNOMED CT, concept codes are available for communicating with external systems. Furthermore SNOMED CT can act as a readily available source of master reference data e.g. allergen list.
Figure 12. SNOMED CT as a dictionary for simple aggregation and analysis of data
Building on the previous implementation approach, the addition of analytics functions using SNOMED CT, as shown in Figure 12, provides enhanced capabilities. For example, this approach enables the identification of cohorts of patients based on given criteria, the ability to review conformance to care standards and responding to mandatory reporting requirements. A key advantage of this approach is that it does not rely on any terminology mappings, either from a local terminology or from an interface terminology. Using SNOMED CT's hierarchies and defining relationships, this approach supports querying and aggregation over health records. Both data analysts and clinicians gain the analytic power from SNOMED CT.
Figure 13. SNOMED CT as a dictionary for analytics using Description Logic
This approach may suit users who value the additional analytics capability that may be achieved with full computational use of SNOMED CT concept definitions. The enhanced analytic capabilities of this approach enables more effective record retrieval by minimizing the occurrence of false negative results, thereby improving the user experience.
In the Reporting and Analytics tools, this approach uses techniques from Description Logic. It does not include the use of SNOMED CT postcoordinated expressions for data entry and storage, however it does exploit the definitions of each SNOMED CT concept based on description logic.
Figure 14. SNOMED CT for knowledge linkage
An enhancement to the approach set out earlier in Figure 11 is the addition of one or more SNOMED CT-enabled knowledge resources. This configuration includes a collection of knowledge resources (such as clinical guidelines or decision support systems) which use the SNOMED CT codes stored in a patient's record to determine which actions should be performed. This may include presenting alerts to the user, displaying relevant clinical guidelines and treatment protocols, or automatically populating an order, message or report.
Figure 15. SNOMED CT as an Extensible Foundation for Representing Clinical Data
Figure 13 showed the exploitation of SNOMED CT concept definitions for analysis, but did not feature postcoordinated SNOMED CT expressions in the patient records. In contrast, the approach illustrated in Figure 15 supports the creation, storage, retrieval and display of records which use postcoordinated SNOMED CT expressions. It does not necessarily feature analytics tools dedicated to postcoordinated content. One reason to adopt this approach is to enable combinations of content to be stored together as a single data field e.g. to record the laterality of a procedure together with the procedure in a single field, rather than using separate fields.
This approach allows a variety of refinements to be made to existing concepts, e.g. 'pneumonia caused by streptobacillus' (as illustrated on page ). An option for this approach is to use a SNOMED CT expression repository to identify, store and share the postcoordinated expressions which have been used. This aspect of the approach is described in the Technical Implementation Guide.
Figure 16. Full use of SNOMED CT to deliver all its powerful features in an EHR
This illustration shows a system in which all components are capable of using and exploiting the full features of SNOMED CT. Throughout the system it is possible to exchange, interpret and use information encoded as postcoordinated SNOMED CT expressions, and to perform analytics using Description Logic.
The collection of approaches listed in this section illustrate that there are a variety of ways by which this 'Full use' can be reached. These approaches can be summarized by considering the set of SNOMED CT features that are used in each:
While the last approach (approach 10) could be considered as a possible target configuration, for most EHR products a staged journey towards a more comprehensive design is most appropriate.