Implementing Snomed CT within national electronic record solutions

The experience and lessons learned from implementation projects have highlighted differences between suppliers, organisations and end users in what supporting SNOMED CT actually means, and the ability of existing solution architectures to support the advanced clinical documentation tool that SNOMED CT provides. In addition to the English Care record Service programme several other nations have “signed up” to utilising Snomed CT within their own national programmes, the most recent being France.

One benefit of utilising Snomed CT is that if clinical data is input by clinicians at the point of care for clinical purposes then accuracy and detail should be improved for clinical care, and be available for downstream reporting and decision support and care pathway functions.   There is therefore an expectation that SNOMED CT will support the implementation of payment schemes including Payment by Results (PbR) and the Quality and Outcomes Framework QoF) within the English NHS. 

SNOMED CT itself is only a part of the solution to addressing the requirements for effective electronic clinical records as a terminology and on its own does nothing unless it is both implemented and used.  The implementation of SNOMED CT requires software applications that exploit its features to meet the real and perceived needs of users.  The users of SNOMED CT are not restricted to end-users who enter or retrieve clinical information and experience SNOMED CT through a configured application that uses the terminology.  Users also include those who design, commission and configure software for use in a particular clinical environment.  

As part of a review, and to help others with their ambition, a solution support model for SNOMED CT has evolved, which assists in promoting communication and understanding between the stakeholders.  This draft SNOMED CT support model considers solution capabilities as follows:

Level 0 systems use existing coding systems.  At the lowest point of the range, no change can be made to the systems to accommodate SNOMED CT.  At the upper end of the Level 0 range, the use of mapping tables may enable some existing stored codes to be translated into SNOMED CT codes for messaging.  If the full benefits of using SNOMED CT are to be realised, systems at this level should not be considered viable solutions and may need to be replaced.

Level 1 systems have internal support for SNOMED CT using existing database structures and information models, but use only pre-coordinated expressions.  Most of the systems which are intended to be implemented today fall into this category.  In the acute sector, these systems are more clinical workflow-oriented rather than patient record oriented.  The exceptions are GP systems which are typically more record oriented and are based on Read version 2 and CTV3 systems.  At the lower boundary of Level 1, systems will have some constraints such as shortened descriptions and/or restricted subsets.  At the upper boundary there are fewer constraints.  A typical constraint with Level 1 will be the use of existing (legacy) code-selection interfaces which are not best suited to searching and referencing SNOMED CT code structures.

Level 2 systems have internal support for SNOMED CT using both pre and post-coordinated content.  This is the support level that most fully exploits the benefits of using SNOMED CT.  For the most part these systems do not exist and will require the development of new user interfaces, database information model and system interfaces. 

Level 2 systems can only converse with other Level 2 systems due to the use of post-coordination within the messaging.  Level 1 systems can send messages to Level 2 systems but cannot guarantee to receive all messages from Level 2 systems as they are unable to handle post-coordinated expressions.  Level 0 systems have, at best, very constrained and inflexible text-based messaging.

Note that although initially considered as support provided by Electronic Patient Record (EPR) systems, the SNOMED CT solution support model discussed here also applies to departmental systems such as theatres and pharmacy.  The issue is whether these systems can communicate with Level 1 type systems using encoded data.  To do so they need to be Level 1 themselves, or a specific mapping function is required between these departmental solutions and the EPR so that appropriate SNOMED CT term translation occurs.

SNOMED CT is not ‘just another coding system’ and its implementation will take some time and require significant development of the solutions.  The adoption of SNOMED CT across and within nations will, by necessity, be incremental.  In this extended implementation period, solution providers will need to support workarounds such as maintaining separate clinical terming and classification coding processes.  Therefore, there will be a mixed population of systems and users that either can or cannot support SNOMED CT.  This presents new problems regarding reporting, mixing, sharing and migrating of data. 

Problem resolution

This paper is presented for readers to comment and discuss the following. An understanding of Snomed CT and solution architecture is required.

• Should the delivery of SNOMED CT be managed by a partnership of all stakeholders to enable decision making and implementation issues to be addressed more readily.
• What would such a partnership look like, are current  governance structures sufficient and/ or  what else is needed
• Should and can these SNOMED CT solution support levels in the following model be used to understand the real capabilities and constraints of existing products and their development roadmaps.
• Should this model be fully defined with suppliers and SNOMED CT authorities.
• Is the model an appropriate communication tool between stakeholders. 
• Where should the responsibilities rest for creating, maintaining and managing clinical content arising from the use of SNOMED CT. 
• How could data migration be best managed to ensure minimum disruption and avoid the potential loss of information while addressing potential incompatibilities between codes.
• Should all purchasers and solution providers develop a roadmap and plans for the step change required to shift to a Level 2 solution.
• Should stakeholders consider the implications of not achieving Level 2 solution support ie full support for post-coordinated expressions.
• What end user implementation strategy should there be to ensure that the issues of a mixed Snomed CT support environment are understood.

 Inter relationships

Figure 1: SNOMED CT in the context of a software application

Error! Objects cannot be created from editing field codes.

Figure 1 illustrates the relationships between clinical terminology, patient records, applications and users. In practice, several different applications are used and these may be separately configured for users in different specialties and disciplines. The role of SNOMED CT is to enable processable representation of meaning in forms that can be shared between a diverse range of disciplines, specialties and software applications.

Applications that deliver terminology services interact with SNOMED CT to support term selection for data entry and to facilitate retrieval and interpretation of stored or communicated information. In some cases, retrieval and interpretation requires binding between the terminology and clinical knowledge resources such as clinical rules to deliver decision support. In other cases, retrieval may be directly supported by defining the relationships in the terminology.

In summary, application software needs to fulfil the following functions to enable the effective use of SNOMED CT:

• provide user interface tools that enable clinical information to be appropriately encoded using SNOMED CT.  As such SNOMED CT supports rich clinical expressions in two main forms; pre-coordinated terms which are ‘pre-defined’ terms and descriptions and post-coordinated expressions, which qualify pre-coordinated terms with additional clinical information such as ‘left/right’, ‘mild/severe’ , clinical approach etc. 
• store encoded information in a manner that represents the relevant SNOMED CT expressions and the contextual information surrounding these expressions
• enable retrieval of encoded data in response to queries to provide individual patient record information, decision support and to enable analysis and aggregation of the information
• permit exchange of the encoded data in accordance with standard communication specifications that retain the integrity of the recorded information.

 
 

The Model

The model defines three broad levels within which several characteristics are noted and which could combine to generate a range of possible sublevels. In each case and to provide greater clarity, the model outlines the characteristics of the least and most functional solution at either end of this range.

While there may be some attraction for defining a larger number of specific levels, this is likely at this stage to lead to contention about the relative importance of the distinguishing features. Furthermore, such distinctions may lead to an inappropriate focus of attention on enhancements within one of the two lower levels rather than on moving to the top level.

These three levels are described in more detail below. 
 

Level 0: No internal support for SNOMED CT

The following tables provide an analysis of the characteristics, issues and likely benefits of a Level 0 support solution. 

 
 

 Evaluation of "low-end" Level 0 support

 
 

 Evaluation of "high-end" Level 0 support

Level 1: Internal support for pre-coordinated SNOMED CT

The following tables provide an analysis of the characteristics, issues and likely benefits of a Level 1 support solution. 

 
 

 

 
 

 Evaluation of "low-end" Level 1 solution support

Evaluation of "high-end" Level 1 solution support

 
 

 

 
 

 Level 2: Internal support for post-coordinated SNOMED CT

The following tables provide an analysis of the characteristics, issues and likely benefits of a Level 2 support solution. 

Evaluation of the range of Level 2 solution support

 
 

 
 

 

Using this model it becomes apparent that while the system implementers and suppliers may implement Level 1 solution support for SNOMED CT, the user experience may be such that users are unwilling to adopt the user interface as it is too unwieldy.  Users may expect that a Level 2 implementation is required in order for the system to meet their expectations. 

SNOMED CT is only appropriate for electronic patient record systems, therefore the pace of change with regard to usability, acceptability and subsequent delivery of benefits is driven by the availability of appropriate solutions (ideally at Level 2).

However, Level 2 solutions will require re-architecting and the development of user interfaces, processes and database and information model structures. This is a long term roadmap and may or may not be incentivised by the international SDO approach.

Meanwhile there is limited development which may beneficially be undertaken to support higher Level 1 solutions, recognising that the step change to Level 2 is intrusive to the systems and therefore higher risk.

Lessons should be learned from the early implementations, which demonstrated that Level 1 implementations (as described above) provide users with a poor experience resulting in users being reluctant to adopt these new systems.  Should solutions be refocused on Level 2 implementations where SNOMED CT is visible to the user, this clearly necessitates new system architectures around user interface, processes and database and information models and is a significant redevelopment.

Entering pre-coordinated expressions

For many of the most common current uses of Clinical Terminology, pre-coordinated data entry is adequate. Minimal changes to the user interfaces already deployed with the Read Codes will also support use of pre-coordinated SNOMED CT. Any information that can be captured using Read Codes can inevitably be recorded in SNOMED CT without recourse to post-coordination. For example, with modest changes to search facilities, a current GP system could enable entry of SNOMED CT encoded data to at least the same level of detail.

The substantial increase in the number of terms and concepts in SNOMED CT as compared to earlier coding schemes may present a challenge. However, effective use of subsets and effective search strategies allow SNOMED CT data entry search performance to equal or improve upon that available in current GP systems. Both Kaiser Permanente HealthConnect (KP) and University of Nebraska Medical Center (UNMC) experiences demonstrate that initial poorly optimised general purpose search tools pose a source of user dissatisfaction, which is removed when more effective searches are enabled.

Entering post-coordinated expressions

All the experiences note the value of data strategies that, to some extent, are sensitive to the context of use. This lesson can also be applied to the entry of post-coordinated data.

• In some situations, a concept needs to be described in detail from a number of orthogonal perspectives. In these cases, a data entry form, which makes the post-coordinated structure explicit, may simplify entry and display of information.

e.g. with a fracture (or other types of localised injuries or lesions) which has different site, laterality and characteristics.

• In other cases the post-coordination is best dealt with entirely invisibly, allowing a single search string to return a post-coordinated expression

e.g.  a simple search for "family history of severe osteoporosis" might be expected to return an appropriate post-coordinated expression displayed as a simple phrase in a search list (i.e. "family history: osteoporosis - severe"). 
 

Conclusion

SNOMED CT as a tool is only viable when used within an electronic clinical system, it has no place in paper records as the clinical detail it supports can never be exploited in manual records and reporting.  It is the nature of the available systems which enables SNOMED CT, if systems are incomplete then SNOMED CT is incomplete and must co-exist alongside other essential (in the current world) codes and classifications that support reporting and essential clinical processes.

As systems push the boundaries of how SNOMED CT can be supported (in terms of simpler user interfaces and exploiting the encoded information to support clinical decision support), there will always be legacy data which is difficult to migrate to an unambiguous new form and to the required level of detail.  Additionally, some users will be in advance of others, making data sharing using the right detail difficult.  Therefore supporting SNOMED CT within solutions requires new databases, new processes and workflow, new reporting frameworks and ongoing maintenance.  These must ensure that SNOMED CT can co-exist alongside other ‘codes’ until every patient record is fully SNOMED CT encoded.

Going forward, care is required when, in the future, local solutions comprise a mix of Level 1 and 2 solution support.   Level 1 solutions cannot interoperate with messages from Level 2 solutions unless the Level 2 solutions comply with the restrictions imposed by each of the Level 1 solutions.  As a result, only when all solutions are Level 2 will the full benefits of SNOMED CT be realised.  At this stage solutions will be built around SNOMED CT and will likely provide sophisticated native SNOMED CT terminology services.  At this point, external (standalone) terminology services are likely to be limited to the distribution/syndication of maintenance releases for clinical content.

This re-engineering of solutions will require significant effort and cost. 

One development is the internationalisation of the management of SNOMED CT through the proposed move from the US CAP to the SDO and regional centres.  It is envisaged that this should provide a more global driver for the adoption of SNOMED CT and increase the market for maintainable SNOMED-centric solutions.

The SDO proposal is a recent development which enhances the acceptability of SNOMED CT as a responsive clinical tool which can be adopted in the NHS.   It provides for more responsive local content management (with regional authoring of content to support local needs above a core product) and provides for less restrictive national licencing.  This should encourage other users within regions, such as private healthcare, and encourage product suppliers to adopt SNOMED-centric product strategies at reduced SNOMED CT licensing costs.

The key risk to SNOMED CT implementations is that financially and politically costly user implementation and technology strategies are developed and implemented without a clear vision for the end point.