SNOMED CT Post-Coordination Rules Guidance Document

SNOMED CT Post-coordination rules
Guidance document
NPFIT-FNT-TO-DPM-0311.01
v0.981Draft

SNOMED CT

Post-coordination rules

Draft guidance document

Amendment History:

Version / Date / Amendment History
Draft 0.8 / 14.11.04 / First Draft Version
Draft 0.8 / 29.11.04 / Incorporation of change recommendations by David Markwell and Ian Arrowsmith. Inclusion of Context-dependent post-coordination proposal
Draft 0.95 / 06.12.04 / Refinement to context-dependent post-coordination proposal
Draft 0.97 / 15.12.04 / Extension of examples
Draft 0.98 / 17.12.04 / Changes in response to NPfIT coordinated review – Martin Tallis, Ian Arrowsmith, Damian Murphy and David Markwell.
Draft 0.98 / 13.01.05 / Minor changes following terminology meeting and, further proof reading and development of ‘link assertion’ solution.

Forecast Changes:

Anticipated Change / When

Reviewers:

This document must be reviewed by the following. Indicate any delegation for sign off.

Name / Signature / Title / Responsibility / Date / Version

Approvals:

This document requires the following approvals:

Name / Signature / Title / Responsibility / Date / Version

Distribution:

Document Status:

This is a controlled document.

This document version is only valid at the time it is retrieved from controlled filestore, after which a new approved version will replace it.

On receipt of a new issue, please destroy all previous issues (unless a specified earlier issue is baselined for use throughout the programme).

Related Documents:

These documents will provide additional information.

Ref no / Doc Reference Number / Title / Version

Glossary of Terms:

List any new terms created in this document. Mail the NPO Quality Manager to have these included in the master glossary above [1].

Term / Acronym / Definition

Contents

1 Summary and purpose 4

2 Associated materials 4

3 Definitions 4

4 Convention for examples 5

5 Principles of post-coordination 5

5.2 Real and ideal data 7

5.3 Future modifications 7

6 Concepts that can undergo post-coordination 7

6.1 Clinical findings 8

6.2 Procedures 8

6.3 Body structures 8

6.4 Observable entities 8

6.5 Context dependent concepts 8

7 Patterns of post-coordination 9

7.1 Sanctioned and allowable attributes 9

8 Post-coordination guidance and strategies 10

9 Input and storage guidance 10

9.2 Input and storage post-coordination strategies 13

9.3 Refinement of defining characteristics 13

9.4 Lateralisation 15

9.5 Selection of qualifying characteristics 21

9.6 Contextual modification 22

9.7 Communication guidance 31

9.8 Retrieval and comparison guidance 31

9.9 Transformation from ‘close-to-user’ forms to normal forms 31

9.10 Transformation risks 35

10 Appendix 1 36

10.1 Defining and qualifying characteristics 36

11 Appendix 2 38

11.1 Archetypical contextual modification 38

1 Summary and purpose

This document describes a set of post-coordination strategies for SNOMED Clinical Terms (SCT). It recognises a tension between the logical requirements of post-coordination, and the practical requirements of human-computer interaction and concept rendering. The solution proposed is therefore based upon more than simply following the rules of the data itself and the logic of canonical form generation. Instead a ‘close-to-user’ form of post-coordination data capture is described, along with an additional layer of logic for transforming this minimal ‘close-to-user’ form into comparable normal/canonical forms. Neither the ‘close-to-user’ form nor the transformation rules are fully tested, however it may be sensible to start discussion and implementation planning with such an approach in mind, since the alternative may well result in the recording of concepts that:

· Are verbose and confusing to render

· Have not actually been selected by the clinician

· Are factually erroneous

Following sections that explain the principles of post-coordination, the concepts that can participate, and the common recommended patterns, more detailed guidance is offered.

It is recognised that this is a complex area, and the solutions proposed are relatively new. They are therefore published as a Draft Guidance, in order to gain feedback on the theory and practical implications, whilst systematic testing as well as National and International consultation takes place. This paper indicates a development direction, and as soon as is possible the document will be published with normative status.

2 Associated materials

Several other documents are referenced from within this paper, and references are given as the abbreviations shown, underlined and in bold text.

SNOMEDCT Technical Implementation Guide 20040731 (TIG)

SNOMED CT Technical Reference Guide 20040731 (TRG)

SNOMEDCT User Guide 20040731 (UG)

SNOMED CT Post-coordination implementation guidance v0[1].5 (PCIG)

Guidance on implementing the SNOMED CT Context Model, Version 1.0 (Context Imp)

Message Genesis and Spine Interactions.doc (Genesis)

3 Definitions

SCTID: A unique identifier applied to each Concept

Post-coordination: describes representation of a Concept using a combination of two or more codes. SNOMED CT allows many Concepts to be represented in a post-coordinated form using a collection of several SCTIDs

Pre-coordination: describes representation of a potentially complex Concept using a single code. SNOMED CT allows many Concepts to be represented in a pre-coordinated form using a single SCTID.

Role group: add clarity to concepts with multiple attribute/value pairs. By example: For a procedure in which there is more than one method and more than one site, role groups associate the correct method with the corresponding site. In this example, the role groups clarify that the exploration occurs at the bile duct, and the excision occurs at the gall bladder:

· Cholecystectomy and exploration of bile duct:

o Role group1

§ Method = Exploration

§ Procedure site = Bile duct structure

o Role group2

§ Method = Excision

§ Procedure site = Gall bladder structure

Sanctioned attribute: attributes that can be applied to each main hierarchy or concept domain, that have actually been modelled (in defining or qualifying characteristics) in those domains.

Defining characteristic: a relationship that is always true from any case of a ‘source’ Concept. For example, 'procedure site=liver structure' is a Defining characteristic of the ‘source’ Concept ‘Liver biopsy’, and is modelled as such in the released data

Qualifying characteristic: a relationship that specifies a possible modification to a ‘source’ Concept. For example, ‘priority=emergency’ is a possible qualifying characteristic of the procedure ‘appendicectomy’, and is modelled as such in the released data.

CharacteristicType: a field in the Relationships Table of SNOMED CT that indicates whether a Relationship specifies a defining characteristic or a qualifying characteristic

Refinability: a field in the Relationships Table, which indicates whether or how to refine the value of a defining characteristic or qualifying characteristic to represent a more refined Concept.

4 Convention for examples

Structured examples of post-coordination use the format of the HL7v3 CD data type as applied to SCT concepts (although note that for brevity codeSystem attribute and value is not shown). Whilst it is acknowledged that this is not the only way to illustrate examples, it is a notation that should be suitable for current readership.

The colour scheme used is as follows – blue sections indicate the ‘starting’ concept, and red sections indicate the modified/additional data resulting from whichever kind of post-coordination is performed. For example, the simple case of:

</qualifier>

</code>

suggests that starting from the concept ‘evacuation of hematoma from cerebellum’, post-coordination has been used to modify this concept with a refined ‘method’ of ‘suction evacuation’.

5 Principles of post-coordination

Post-coordination is the process of explicitly and meaningfully combining SCT concepts in order to express distinct clinical phenomena.

The use of post-coordination is logically acceptable if it is possible to compare equivalent expressions, and expressions are sensibly comparable when converted into their logical normal/canonical forms [TRG ch7; TIG ch6.7.2, App F; UG p65]. The temptation may therefore be to store data immediately (i.e. at the time it is input or ‘first’ coded) in a form that requires the least effort to convert into canonical forms. However, analysis of examples would suggest the risk of such a ‘retrieval and comparison’-dominant approach is that it may result in inappropriately complex default input mechanisms, as well as the creation of expressions stored at the input stage (referred to in this document as ‘close-to-user’) which may contain concepts that:

· Together are verbose and confusing to render

· Have not actually been selected by the clinician

· Are factually erroneous (see section 5.2 Real and ideal data)

Such a solution is unattractive, and therefore the principles and strategies for post-coordination that are recommended in this document try to simplify common input mechanisms (whilst supporting complex mechanisms when needed), and in all cases should result in the capture of sufficient information to allow consistent and accurate transformation to canonical forms for comparison purposes.

As understandings and experience improves, it is likely that changes to these recommendations will be made, but as suggested in section 5.3 Future modifications, changes should not radically revise those presented here.

The following sections consider each axis of interest for post-coordination of SCT data. Each axis is taken in turn, considering the relative preferences for input-dominant (‘close-to-user’) post-coordinated expressions and logically comparable ‘normal/canonical’ post-coordinated equivalent expressions.

5.1.1 Input

The goal of data input is to enable accurate, clear and faithful capture of coded clinical information. This document makes no specific assumptions about actual data input paradigms used. On occasions post-coordination will require more complex interactions with the underlying terminology data (e.g. the ability to select co-grouped attribute/value pairs) – if so, input processes are likely to be necessarily more complex and prescriptive.

5.1.2 Storage and communication

‘Close-to-user’ storage (i.e. the storage of post-coordinated data at the input stage) will preferably be as ‘light’ as possible – storing and attributing only what has been actively selected, whilst still storing ‘enough’ for consistent and accurate transformation to canonical forms for comparison purposes. Once transformed into any logically equivalent alternative form, what should be stored must be sufficient to satisfy the uses to which they are put. In either case, the same principles will apply to communication.

5.1.3 Retrieval and comparison

The optimal form of post-coordinated data will depend on the uses to which it is put. If formal concept comparison is required, then normal or canonical forms of all concepts (whether originally pre-coordinated or post-coordinated) may be the ideal.

5.1.4 Transformation between stored forms

Put simply, transformation between ‘close-to-user’ and comparable/canonical forms requires sufficient information to perform the transformation, and this is itself dependent on the sophistication of the transformation rules, as well as the reliability of the assumptions upon which such rules are based.

5.1.5 Rendering

Rendering is used here to mean the generation of human-readable expressions from post-coordinated groups of concepts. Rendering of post-coordinated data may be required at any point in the ‘life-cycle’ of recorded data, however it is perhaps fair to say that:

‘Close-to-user’ rendering should accurately and economically reflect the concepts that have been actively selected, and should be easy to read and understand. In other circumstances (such as validation of decision support reasoning which may be based on logically transformed data), it will be more appropriate that a more elaborate (but equally accurate) reference rendering is generated.

5.2 Real and ideal data

Despite skills, tools and processes to maximise quality, SCT data is unavoidably a ‘human’ artefact, and thus prone to errors. Theoretically we might assume that ‘ideal’ data would have the following properties:

1. Completeness and accuracy of modelling

2. Non-redundancy of modelling

These properties would apply to all relevant areas of SCT. The modelling of defining and qualifying characteristics would need to be complete, accurate and non-redundant for appropriate ‘clinical finding’ and ‘procedure’ concepts, for ‘body structure’ concepts (specifically laterality modelling) and context-dependent concepts (specifically context modelling).

It is fair to say, however, that SCT data has not yet achieved this ‘ideal’ state, and is instead ‘real’, meaning that post-coordination strategies need to accommodate data that may contain incomplete, inaccurate and redundant data.

In particular, it is recognised that concepts may lack modelling (clinically lateralisable concepts that do not have site-based defining characteristics), or may be modelled with a surplus of particular defining characteristics – often this is associated with a surplus of role-grouped relationships.

The post-coordination strategies suggested will not completely shield the user from the flaws of ‘real’ data, but strive to minimise its impact on normal workflow, and on subsequent concept retrieval and comparison. Likewise, an on-going data improvement programme for SCT is steadily reducing instances of erroneous modelling.

5.3 Future modifications

Possible modifications to post-coordination that are anticipated are:

· Modifications to the technical solutions for representing refinability instructions. Currently these instructions are fixed for each release in the Relationships table. Their values restrict concept combination rules for all users of that data. A preferable alternative solution might be to allow localisation of refinability instructions to individual realms, allowing realm-specific refinability solutions which may better harmonise with corresponding realm-specific information model solutions.

· Development of artefacts such as navigational hierarchies to aid common refinements (e.g. "skin" to "skin of arm" rather than either having to traverse the full subtype hierarchy or allowing access to logically correct but contextually inappropriate subtypes such as "skin cell").

· If insoluble difficulties are encountered with the ‘close-to-user’+transformation solution described in this document, then the post-coordination could still be drawn from the more complex strategies presented, and disallow the ‘close-to-user’ alternatives, regardless of the nature of the released data or the significance of role grouping. Whilst perhaps satisfying the ‘concept equivalence’/comparison, such a logically dominant approach may compromise the ease of interface design, input strategies and concept rendering.

6 Concepts that can undergo post-coordination

This section describes those concept types that may have their definitions modified by one or more Patterns of post-coordination (described in section 7). Working definitions for each of these concept types are provided in the UG [pp27-37].

6.1 Clinical findings

Clinical finding concepts (currently in the descent of 404684003) can be post-coordinated along a number of the modelled axes shown in TRG app J according to the refinability rules in Appendix 1.