SCT postcoordination
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
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.
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)
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.
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:
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’.
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.
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.
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.
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.
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 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.
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.
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.
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].
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.
Whilst not an ‘allowable attribute’ in TRG app J, this guidance document also recommends that it will be possible to apply laterality to appropriate clinical finding concepts – a process referred to as indirect lateralisation. See section 9.4 Lateralisation for details.
Clinical findings can also function as the target of an ‘associated finding’ attribute of a context dependent concept, with other aspects of context-dependent modification represented using the attributes ‘finding context’, ‘temporal context’ and ‘subject relationship context’.
2 Procedures
Procedure concepts (currently in the descent of 71388002) can be post-coordinated along a number of the modelled axes shown in TRG app J according to the refinability rules in Appendix 1.
Whilst not an ‘allowable attribute’ in TRG app J, this guidance also recommends that it will be possible to apply laterality to appropriate procedure concepts – a process referred to as indirect lateralisation. See section 9.4 Lateralisation for details.
Procedures can also function as the target of an ‘associated procedure’ attribute of a context dependent concept, with other aspects of context-dependent modification represented using the attributes ‘procedure context’, ‘temporal context’ and ‘subject relationship context’.
Procedures, if accompanied by a value (generally the result of a ‘measurement procedure’), can also function as the target of an ‘associated finding’ attribute of a context dependent concept, with other aspects of context-dependent modification represented using the attributes ‘finding context’, ‘temporal context’ and ‘subject relationship context’.
3 Body structures
Body structure concepts (currently in the descent of 123037004), can be post-coordinated by the selection of laterality qualifier values.
4 Observable entities
Observable entities (currently in the descent of 363787002), are not modelled for any form of post-coordination (as shown in TRG app J). However:
Observable entities unaccompanied by a value can function as the target of an ‘associated procedure’ attribute of a context dependent concept, with other aspects of context-dependent modification represented using the attributes ‘procedure context’, ‘temporal context’ and ‘subject relationship context’.
Observable entities, if accompanied by a value (generally the result of a ‘measurement procedure’), can also function as the target of an ‘associated finding’ attribute of a context dependent concept, with other aspects of context-dependent modification represented using the attributes ‘finding context’, ‘temporal context’ and ‘subject relationship context’.
5 Context dependent concepts
Context dependent concepts (currently in the descent of 243796009) can be post-coordinated by refinement along the modelled axes shown in TRG app J. See the section 9.6 Contextual modification for current details.
Patterns of post-coordination
This section describes the various patterns of post-coordination that can be performed on the concept groups listed in section 6 Concepts that can undergo post-coordination.
1 Sanctioned and allowable attributes
In the earlier discussion document [PCIG] it is argued that systems would need to support a number of post-coordination variants. Whilst largely unchanged, it is now recommended that post-coordination is restricted to that dictated by the distributed data. – the main consequence being the withdrawal of a requirement to support, at present ‘allowable but un-sanctioned attributes/qualifiers’. It is suggested that post-coordination by concept combination is still not supported [TIG 7.2.8.6].
The consequence of this guidance is that two principal types of post-coordination should be supported:
• Refinement of defining characteristics
• Selection of sanctioned qualifying characteristics
Two tables in the official SCT documentation explain both the allowable attributes for each domain [TRG App J Table 1] and the allowable values types for each attribute [TRG App J Table 2]. Precisely where a defining or qualifying characteristic can be used for purposes of post-coordination is determined by the released data, both in terms of what defining and qualifying characteristics are modelled, and the refinability instructions for each characteristic. The refinability instructions are summarised in Appendix 1.
Working definitions for each participating attribute are provided in the UG [p38-52].
The only immediate exceptions to this restriction relate to the capture of laterality – see below.
1 Refinement of defining characteristics
This pattern of post-coordination is described in the TIG [7.2.8.2], and refers to the selection of a subtype of a defining characteristic. For example, the concept ‘fracture of femur’ can be modified by refinement of its defining characteristic ‘finding site=bone structure of femur’, to select one of the subtypes of ‘bone structure of femur’.
2 Lateralisation
Whist in principle an example of refinement of defining characteristics, concept lateralisation is a sufficiently special case to be described in a distinct section. Some of the issues around this pattern of post-coordination are elaborated in the TIG [App D.4.4].
3 Selection of qualifying characteristics
This pattern of post-coordination is described in the TIG [7.2.8.3], and refers to the selection of a qualifying characteristic, or one of its subtypes (depending on refinability instructions). To continue the ‘fracture of femur’ example, it should be possible to modify this disorder by the selection of, for example, ‘severity=severe’.
4 Contextual modification
Whilst the principles of application are documented elsewhere, it is recognised that the recording of contextually modifying/modified information in SCT will often involve concept post-coordination (the exception being the selection of pre-coordinated context dependent content – in the descent of 243796009: context-dependent categories – where the explicit representations of the context modifications should already be expressed in the modelled data).
Post-coordination guidance and strategies
Expanding on the principles of post-coordination presented earlier, this section describes both the principles in more detail, as well as the set of strategies suggested for each pattern of post-coordination.
Input and storage guidance
1 Input
1. The user interface should enable the refinement of sanctioned defining characteristics (e.g. refinable sites, methods and morphologies), and the selection of qualifying characteristics:
a. Where single instances of any refinable attribute/value pairs exist, the option to refine them should be offered. The nature of the data in SCT is such that there will only be single instances of each qualifying characteristics for any concept.
b. Where multiple instances of any refinable attribute/value pairs exist, the option to refine any distinct attribute/value pairs should be offered – for 'real data' this will allow a user to refine the most appropriate value for a given attribute where redundant modelling is present. Do not offer the same attribute/value pair from different groups unless it is significant that any refined attribute/value is explicitly grouped with another attribute/value (see c).
c. If it is significant that any refined attribute/value is explicitly grouped with another attribute/value (whether refined at input or not), then options to specify which refinements to apply to which groups should be offered. However, these should be requested as additional options, and not exposed as a default.
2. The user interface should enable selection of laterality:
a. Easily in any cases where one procedure or finding site exists that is lateralisable (e.g. by use of option boxes).
b. With more difficulty where there is no site or no lateralisable site. (e.g. in this case the user may be provided with some way to see additional options). The reason for this feature is explained in the detailed section on Lateralisation (9.4).
c. Where multiple sites are lateralisable, but lateralisation can sensibly be applied to the whole ‘concept’, provide a single simple approach that lateralises all sites involved.
d. Where multiple sites are lateralisable but different lateralisation should be applied to different components, an extended option should be offered (note - the user may have to explicitly request this, but should not see complex options by default).
e. Where multiple groups contain same or different sites, options to specify which lateralisation refinements apply to which groups may be offered. However, these should be requested as additional options and should not be exposed by default as they will rarely be needed.
Note - for situations such as 1 b-c and 2 c to e: The judgement as to what postcoordination principle applies (e.g. whether a concept needs multiple lateralisations or not) will not be always automatically derivable from the released SCT data. Interface prioritisation strategies cannot therefore be driven entirely by the SCT data, and will require varying strategies to be supported and selected depending on clinical need.
3. Where the user interface provides highly structured entry screens these can be used to capture SNOMED CT coded data. In these cases the encoding of laterality and other site refinements need only be captured to the same level as for user selection (as in 1 and 2 above).
4. Where user interface provides auto/semi-auto encoding of text the structured information encoded should fully capture the sense of the text. It should not add to this and thus should follow principles of similar to those outlined above.
2 Storage
1. The primary rule/goal is to store data in a form that is as close to that entered as possible. This should avoid adding additional/verbose groupings or association with specific sites, methods etc. unless this was explicitly entered by the user. This is the principle of ‘close-to-user’ storage and retrieval.
a. Any transformation for retrieval or analysis is secondary to this primary recording. As is suggested for the representation of canonical/normal forms, alternative representations should be stored as annotation, index or pointers to normal forms based on the most recent SCT release rather than historical data.
b. A ‘close-to-user’ primary recording should help in avoid errors in subsumption computation from co-recorded grouped attributes that were not directly specified by the clinician AND which have in subsequent release been refined or removed in the SNOMED CT definitions. Using the latest released definitions is better than using SNOMED CT generated data at time of creation EXCEPT in cases where explicitly selected by author.
2. Where information is entered in a way that sensibly and explicitly distinguishes grouped characteristics (e.g. sites grouped with methods or morphologies), or sites that are individually lateralised (such as suggested in section 9.1.1 Input parts 2.d and 2.e) this associated information does need to be stored.
3. Requirements for storage include the ability to (1) represent grouping between attributes and (2) the nesting of attributes within the values of other attributes. However, these facilities should only be used where these structures are required by the nature of the information as entered (not simply because a concept has role grouped relationships).
3 General storage requirements
The official SCT documentation does not specify a single best way of storing post coordinated data [TIG 7.3 et seq.], instead it enumerates a number of alternative logical solutions. This document does not significantly modify the spectrum of technical guidance. Nevertheless, given the consequences of current depth/nesting of allowable post-coordination, the following guidance may be helpful in planning, for example, the schema of related tables required for an unrestricted relational solution.
SCT post-coordinated concept expressions will have a general form of:
C:A1=V1,A2=(V2),…,An=Vn{A1.1=V1.1,…,A1.n=V1.n}…{Ag.1=(Vg.1),…,Ag.n=Vg.n}
The components of this expression are explained in Table 1:
|C |is the base-concept (a ConceptId) |
|An |is the name of the nth ungrouped attribute (a ConceptId) |
|Vn |is the value of the nth ungrouped attribute (a ConceptId or bracketed expression*) |
|Ag.n |is the name of the nth attribute in the gth group (a ConceptId). |
|Vg.n |is the value of the nth attribute in the gth group. |
| |(a ConceptId or bracketed expression*) |
|: |separates a concept from attribute value pairs that define, qualify or refine it. |
|= |separates an attribute from its value. |
|, |separates attribute-value pair from one another. |
|{} |represents a group of attribute-value pairs. |
|… |represents repetition of the surrounding elements. |
|(V) |represents by example the fact that a value may be expressed as a bracketed |
| |nested-expression with the same form as the general expression. This occurs in two cases: |
| |Within a context dependent expression |
| |For qualifying site (e.g. by laterality) |
Table 1: post-coordinated expression notation
A schematic/modification of an HL7v3 CD data structure is shown in Figure 1, in order to illustrate the current sanctioned ‘depth’ of post-coordination, and therefore inform anticipated storage and communication requirements. Working from the ‘inside’ outwards:
C can be the SITE VALUE of a SITE ATTRIBUTE of a finding or procedure (purple box and panel). In this case, C will only be associated with a single ungrouped attribute value pair of ‘laterality=LATERALITY VALUE’ [A=V] (the square brackets enclose fragments of the above expression syntax).
Moving ‘outwards’, C will often be a CLINICAL FINDING or PROCEDURE concept (green box and panel). In this case:
• C may be associated with any number of ‘UN-GROUPED ATTRIBUTE=UN-GROUPED VALUE’ pairs [A1=V1,…,An=Vn].
• C may be associated with any number of ‘GROUPED ATTRIBUTE=GROUPED VALUE’ pairs, whether in the same group [{A1.1=V1.1,…,A1.n=V1.n}], or in several groups [{Ag.1=Vg.1,…,Ag.n=Vg.n}].
• In either of the above circumstances, V will simply be a single VALUE concept unless A is a SITE ATTRIBUTE, in which case V may be a nested expression of ‘laterality’ [(V) or(Vg.n) ] as for the purple panel.
Finally, C may be a CONTEXT DEPENDENT CONCEPT (yellow box and panel). In this case:
• C will be associated with a set of ‘GROUPED CONTEXT ATTRIBUTE=GROUPED CONTEXT VALUE’ pairs [{A1.1=V1.1,…,A1.n=V1.n}].
• The value of the ASSOCIATED FINDING/PROCEDURE attribute will be a CLINICAL FINDING/PROCEDURE concept (or an ‘observable entity’ concept – not shown here), which may:
o Be a single VALUE concept [A1.1=V1.1].
o Be a nested expression [A1.1=(V1.1)], as for the green panel.
[pic]
Figure 1: Schematic of depth of sanctioned post-coordination
2 Input and storage post-coordination strategies
This section offers detailed guidance regarding post-coordination ‘strategies’ that should be supported. They are intended to be both consistent with the guidance statements above, and also to allow subsequent sensible and consistent transformation from ‘close-to-user’ forms to normal forms as described in that section.
3 Refinement of defining characteristics
The refinement of defining characteristics strategies that should be supported are summarised in Figure 2:
[pic]
Figure 2: refinement of defining characteristics strategies
1 Explanation
Figure 2 reads from left to right. For each ‘refinable’ concept, depending on the pattern of released data and the significance (or not) of preserving role grouped assertions, differing input strategies are proposed as most appropriate, and following these, most appropriate storage strategies.
Input strategies RI1 and RI2
Input strategies RI1 (e.g. ‘Refinement-Input-1’) and RI2 will both result in the storing of a single attribute/refined value pair (RS1 - e.g. ‘Refinement-Storage-1’), however RI2 requires an input choice to be made for selecting the most appropriate value to refine.
Examples of RI1 are the refinement of the defining characteristic method=evacuation (single application in current data) as shown:
Similarly, for multiple identical defining characteristics finding site=eye structure (two applications in current data):
As and example of RI2, the concept 297143008 suprarenal artery embolus has two associated morphology defining characteristics – with values of =obstruction and =embolus (this makes no judgement as to the appropriateness of the definitional modelling). Both these values are refinable, and yet it may be desirable to refine only the ‘embolus’ value (to, for example, ‘septic embolus’). If this is the case, then the input strategy should allow the user to refine the appropriate value (here ‘embolus’):
As for RI1, this would still only require and RS1 storage pattern.
Input strategy RI3
Input strategy RI3 (and storage strategy RS2) will serve cases of complex source data and clinical relevance of role grouping. Such a pattern assumes pre-existing complex/compound clinical concepts. A preferable recording solution might better be to record complex or compound phenomena with multiple separate statements.
To illustrate the case of ‘multiple attributes, identical values and significant role groups’, the example of 75857000: fracture of radius and ulna can be used. If it were important to refine the morphology=fracture defining characteristic associated with the ulna alone (to, say, ‘spiral fracture), an RI1 approach would not capture this association. Instead, an explicit association is required, thus:
4 Lateralisation
Whist in principle an example of refinement of defining characteristics, concept lateralisation receives special consideration. Arguably no nuance of clinical information should be given supremacy over another, however for purposes of clarity and patient safety this paper suggests that:
• It will be preferable to capture laterality in an interoperable coded form, and therefore solutions offered should result in minimal obstacles to the coded capture of laterality. Alternatives may include the recording of laterality for findings and procedures in non-standard forms such as free text.
• Where laterality is recorded, the resultant ‘close-to-user’ form should allow rendering of laterality without noise from the redundant recording of (1) otherwise un-refined sites and (2) non-significant or un-modified role grouped characteristics.
The strategies for lateralisation are therefore closely related to refinement of defining characteristics, but include additional mechanisms for identification of lateralised concepts. The strategies are illustrated in Figure 3:
[pic]
Figure 3: lateralisation strategies
1 Explanation
Figure 3 reads from left to right. For each ‘lateralisable’ concept, depending on the pattern of released data, the significance (or not) of preserving role grouped assertions, and clinical over-ride of released data, differing input strategies are proposed as most appropriate, and following these, most appropriate storage strategies.
The major extensions to the strategy pattern for subtype refinement relate to (1) the distinct recording of selecting pre-coordinated lateralised concepts and (2) the opportunity to use ‘indirect lateralisation’.
2 Pre-coordinated lateralised concepts
Such concepts receive a special mention since current SCT data contains a number of pre-coordinated lateralised concepts. Not all are modelled with lateralised site values, so until the data is ‘ideal’, such concepts may need special consideration for data retrieval purposes.
By example:
For the concepts: ‘right salpingectomy’ 176916000 or ‘acute right otitis media’ 194289001 – in current data these concepts are modelled with appropriate lateralised site characteristics (‘structure of right fallopian tube’ and ‘right middle ear structure’ respectively).
For the concepts: ‘right renal arteriography’ 287581009 or ‘left hemiplegia’ 278285008 – in current data these are not lateralised concepts, but this should not preclude their selection to record explicitly lateralised procedures and findings.
This form of laterality recording is supported by input strategy LI1 and storage strategy LS1 (Figure 3).
3 Direct and indirect lateralisation
As discussed in SCT documentation [TIG D.4.4], lateralisation of a concept may be achieved by associating the laterality with either one or more body structure concepts (that are themselves values of ‘finding or procedure site’ attributes), or by associating the laterality with the concept itself. For the purposes of this document these strategies are referred to as direct and indirect respectively, illustrated by the following examples:
Direct lateralisation
To record ‘fracture of right radius’ by direct lateralisation:
Here, the ‘laterality, right’ data (red) is recorded as a attribute/value pair of the bone structure of radius object concept.
Indirect lateralisation
To record ‘fracture of right radius’ by indirect lateralisation:
Here, the ‘laterality, right’ data (red) is recorded as a attribute/value pair of the fracture of radius object concept (in blue).
As will be seen, the decision to use direct or indirect lateralisation is dependent on a number of variables. Given the way SCT applies laterality within its own definitional model (‘directly’, to body structure values), direct lateralisation might be regarded as a purer approach, and certainly is the required form for equivalence detection purposes (‘indirect’ representations of laterality would need to be transformed into ‘direct’ laterality). However, in certain cases, ‘indirect’ lateralisation has an attractive ‘economy’ and simplicity to its use, and can avoid the redundant recording of otherwise un-modified data, and would therefore be more suitable for ‘close-to-user’ recording.
It is recommended that direct lateralisation is used in any cases where non-lateralising site value refinement has also taken place (e.g. if the site ‘bone structure of radius’ were refined to ‘bone structure of distal radius’). Indirect lateralisation is recommended for those cases managed by strategies LI2 and LI3.
Input strategy LI2
This strategy would allow the ‘indirect lateralisation’ of concepts which have single (or multiple identical) lateralisable sites modelled, and for whom only one lateralisation assertion is required (e.g. just ‘Right’ or just ‘Left’ for the whole concept).
By example:
For the concepts ‘traumatic amputation of leg’ 95860004 or ‘nephrectomy’ 108022006 – in current data these concepts are modelled with anatomically appropriate lateralisable site characteristics (‘lower limb structure’ and ‘kidney structure’ respectively), and could be lateralised indirectly as:
and
For the concept ‘abscess of eye’ 95679004 – in current data this concept is modelled with multiple identical anatomically appropriate lateralisable site characteristics (2x ‘eye structure’), and could still be lateralised as:
Input strategy LI3
This strategy would allow the lateralisation of concepts that might not automatically be presented for lateralisation. Despite modelling shortcomings in ‘real’ data, it is probably fair to say that the vast majority of lateralisable concepts are modelled with lateralisable site values. Nevertheless, there is an incompletely detectable set of concepts that either have no site modelled at all, or have a non-lateralisable site modelled.
Current examples include ‘dyspraxia of arm’ 102561001 (no site modelled) and ‘compartment syndrome decompression of upper limb’ 281784009. In current data this latter concept has an anatomically appropriate site characteristic (‘structure of fascia of upper limb fascial compartment’), which is, however, un-lateralisable.
In the spirit of the lateralisation discussion as above, it would seem desirable for shortcomings in release data not to be an obstacle to lateralisation. It is still suggested that the principal guide to whether a concept might be lateralised (and thus to the default input processes for such concepts) should be the laterality instructions of the data, but such a feature can be over-ridden if clinically indicated.
The LI3 pattern is therefore the only current example of ‘allowable’ post-coordination – that is, post-coordination according to the rules of allowable attribute and value distribution [TRG App J tables 1 & 3].
In the case of both concepts with no associated site (e.g. 102561001: dyspraxia of arm) and concepts with apparently non-lateralisable associated sites (e.g. 281784009: compartment syndrome decompression of upper limb) the default storage strategy will be indirect lateralisation. It is theoretically possible that a concept with one or more non-lateralisable associated sites may require representation using direct lateralisation (e.g. LS3 & LS4), but no examples of this pattern of data distribution have been detected.
The occurrence of LI3 post-coordination indicates a problem with the source of the data. Ideally each time it is supported (to allow un-interrupted clinical workflow), the terminology service will be alerted, so that the terminology can be improved in subsequent releases. As the SCT data improves in quality, the canonical forms generated on each new release of data will evolve accordingly.
Both input strategies LI2 and LI3 will be served by storage strategy LS2.
Input strategy LI4
This strategy (and its accompanying storage strategy LS3) will allow the recording of non-grouped mixed lateralisation. Whilst perhaps not perfectly modelled, the concept ‘iliofemoral crossover graft’ 233381005. Both ‘femoral artery’ and ‘iliac artery’ procedure sites are in the same group, and it may be desirable to lateralise each differently. On these cases, even if the site value has not been refined (apart from lateralisation), the site value will be recorded as well as the assertion of laterality. The refined site could therefore be a pre-coordinated lateralised site.
By example:
To represent the concept ‘right iliac to left femoral artery crossover graft’, this could be achieved by:
or
Input strategy LI5
This strategy (and its accompanying storage strategy LS4) will allow the recording of group-significant mixed lateralisation. As an illustrative example, it may be desirable to specify differing excision methods for a right ovary and a left fallopian tube. In order to preserve these associations, it should be possible to specify them at the time the record entry is made, and for this specification to be preserved in the recorded data:
In the longer term, a balance will need to be struck regarding the suitability of representing compound and complex concepts as single coded entities or as co-recorded separate procedure or finding ‘parts’. SCT currently has a mixture of both, and experience will help produce workable guidance.
5 Selection of qualifying characteristics
The selection of qualifying characteristics strategies that should be supported are summarised in Figure 4:
[pic]
Figure 4: qualifier strategies
1 Explanation
Figure 4 reads from left to right. For each ‘qualifiable’ concept, depending on the pattern of released data and the refinability of each qualifying attribute/value pair, differing input strategies are proposed as most appropriate, and following these, appropriate storage strategies.
An example of qualification by mandatory sub-type selection (QI1/QS1) is:
Here, for the qualifier ‘priority’, the value ‘emergency’ has been selected – the stated supertype value (‘priorities’) would not contribute to a meaningful clinical statement.
An example of qualification by optional sub-type selection (QI2/QS2) is:
Here, for the qualifier ‘using’ the value ‘forceps’ has been selected – it would be appropriate to select ‘forceps’ or any sensible sub-type to refine this concept.
6 Contextual modification
Note: what follows describes one approach to the composition of context-dependent post-coordinated concepts. It describes the construction of post-coordinated expressions from qualification of suitable new abstract context-dependent concepts. A solution based on sub-type refinement of defining relationships of a less restricted set of context dependent concepts may well be preferable, and will be published and incorporated as suitable refinable concepts are identified, depending on priority.
The coded representation of (potentially) axis-changing concept modification is described in the document Context Imp. Independent of the data input paradigm used, a coded representation of ‘context modified’ content can be achieved by three principal means, here illustrated by the example ‘family history of chronic obstructive lung disease’:
1. The selection of a pre-coordinated ‘context-dependent concept’
2. The refinement of the appropriate attribute-values(s) of a relatively abstract defined ‘context-dependent concept’
3. The ‘contextual’ enrichment of a non-context-modified concept (e.g. a finding, disorder or observable entity – see section 9.6.1.1 Concept behaviour below), either as a result of an explicit clinical assertion (e.g. ‘finding - not present’, and noting the caveats about the free text representation of axis modifying information in Context Imp [section 7.2]), or because of the placement of the entry within a particular part of a record or document (e.g. the placement of the disorder ‘chronic obstructive lung disease’ in a ‘family history’ section of a patient record):
The example in 3 show the ‘chronic obstructive lung disease’ concept being ‘surrounded’ by the same pre-coordinated ‘family history of disorder’ concept as refined in example 2. With the exception of the colour highlight these two representations are identical. The canonical forms of each example will be equivalent. Such an approach requires:
The identification (and specification for use) of several pre-coordinated context-dependent concepts to satisfy the various combinational permutations for contextual modification, and guaranteeing that their definitional modelling is complete and consistent with the guidelines in Context Imp. At the time of writing a full set of such concepts has not been released and completion of this work depends on prioritisation of SNOMED content development. Once such a set of concepts is identified, it will be made available. Likewise, the use of concepts such as ‘family history of chronic obstructive lung disease’ in example 1 will be suitable for human interpretation, but any machine-processing based upon definitional modelling will require the definitions to be accurate and complete – at the time of writing most but not all such pre-coordinated context-modified concepts have been modelled. The timing of completion of the modelling process depends on prioritisation of SNOMED content development.
Given these uncertainties, as well as the difficulties in providing defined, abstract concepts to allow the post-coordination of findings, procedures and observable entities in different settings (see section 9.6.1.1 Concept behaviour below), the following approach to post-coordinating context modification is proposed, as an extension to the example pattern in example 3.
1 Contextual modification by qualification of suitable new abstract concepts
Two abstract context dependent concepts will be modelled as shown in Table 2 and Table 3. By the presence of their stated Defining and Qualifying characteristics, they will technically sanction the construction of context-dependent concepts from non-context-dependent concepts (e.g. findings, disorders or observable entities). Additional constraints are provided in subsequent text, and in combination these new concepts and constraints should allow the creation of context-model consistent concepts.
|Concept Id |413350009 | |
|FullySpecifiedName |Context-dependent finding (context-dependent category) |
|PreferredTerm |Context-dependent finding |
|Synonym |finding modified by context |
|IsPrimitive |0 (i.e. FULLY DEFINED) |
| |CharT|Refin|RelGr|
|Relationships |ype |abili|oup |
| | |ty | |
|RelationshipType |ConceptId2 | | | |
|116680003 | is a |243796009 | context-dependent categories |0 |0 |0 |
|408729009 | finding context |410514004 | finding context value |0 |2 |1 |
|408731000 | temporal context |410510008 | temporal context value |0 |2 |1 |
|408732007 | subject relationship context |125676002 | person |0 |2 |1 |
|246090004 | associated finding |404684003 | clinical finding |1 |2 |1 |
|246090004 | associated finding |71388002 | procedure [with value] |1 |2 |1 |
|246090004 | associated finding |363787002 | observable entity [with value] |1 |2 |1 |
|246090004 | associated finding |163591000000102|Link assertion (link assertion) |1 |2 |1 |
Table 2: Abstract context-dependent finding concept
|Concept Id |129125009 | |
|FullySpecifiedName |context-dependent procedure (context-dependent category) |
|PreferredTerm |context-dependent procedure |
|Synonym |procedure modified by context |
|IsPrimitive |0 (i.e. FULLY DEFINED) |
| |CharT|Refin|RelGr|
|Relationships |ype |abili|oup |
| | |ty | |
|RelationshipType |ConceptId2 | | | |
|116680003 | is a |243796009 | context-dependent categories |0 |0 |0 |
|408730004 | procedure context |288532009 | context values for actions |0 |2 |1 |
|408731000 | temporal context |410510008 | temporal context value |0 |2 |1 |
|408732007 | subject relationship context |125676002 | person |0 |2 |1 |
|363589002: associated procedure |71388002 | procedure |1 |2 |1 |
|363589002: associated procedure |363787002 | observable entity |1 |2 |1 |
Table 3: Abstract context-dependent procedure concept
Both concepts will be added as direct descendants of 243796009 ‘context-dependent categories’. ‘Context-dependent finding’ and ‘Context-dependent procedure’ will allow the construction of valid context-modified variants of findings, procedures and observable entities, according to the additional guidance described in sections 9.6.1.1 Concept behaviour and 9.6.1.2 Additional context constraints.
1 Concept behaviour
For contextual modification purposes, concepts must either be regarded as ‘findings’ (and have ‘finding context’ applied) or regarded as ‘procedures’ (and have ‘procedure context’ applied), but never both. Other context-attributes (‘temporal’ and ‘subject relationship’) are set according to a combination of:
• The nature of the modifying clinical assertion
• The placement of the concept within a record, document of message component
• Default context value settings
The following concepts can behave as if they are ‘findings’:
Subtypes of ‘Clinical finding’ (404684003)
Subtypes of ‘Procedure’ (71388002) if accompanied by a value
Subtypes of ‘Observable entity’ (363787002) if accompanied by a value
Subtypes of ‘Link assertion’ (163591000000102)[1]
This means that they will function as the target of the ‘Associated finding’ attribute of ‘Context-dependent finding’.
The following concepts can behave as if they are ‘procedures’:
Subtypes of ‘Procedure’ (71388002) NOT accompanied by a value
Subtypes of ‘Observable entity’ (363787002) NOT accompanied by a value
This means that they will function as the target of the ‘Associated procedure’ attribute of ‘Context-dependent procedure’.
The variable behaviour of ‘Procedure’ and ‘Observable entity’ concepts benefits from further expansion thus:
1 Terminology perspective on concept behaviour
Within the scope of the currently sanctioned SCT context model, ‘Procedure’ and ‘Observable entity’ concepts can theoretically be modified by:
• Temporal context
• Subject relationship context
• Finding context
• Procedure context
If the required nuance can be expressed by ‘temporal context’ and/or ‘subject relationship context’ only, then ‘Procedure’ and ‘Observable entity’ concepts will behave as procedures.
If the required nuance can be expressed by ‘procedure context’ then ‘Procedure’ and ‘Observable entity’ concepts will behave and be modelled as procedures.
If the required nuance can be expressed by ‘finding context’ then the ‘Procedure’ and ‘Observable entity’ concepts will behave and be modelled as findings. Such modelling would therefore be allowable within SCT (i.e. the creation of pre-coordinated concepts of this form), however for an actual record entry, the ‘Procedure’ or ‘Observable entity’ concepts behaving as findings must be associated with an appropriate value.
For example:
(1) observable entity behaving as a procedure – ‘urine volume measurement requested’, shown including all soft defaults:
(2) observable entity behaving as a finding – ‘target urine volume’ (+ value = 2 litres/24 hours), shown with soft defaults:
Note 1: the sensible use of this latter form for an actual record entry requires its association with an appropriate value – in this example 2 litres/24 hours. Such conditional constraints cannot currently be expressed within the distributed data of SCT.
2 HL7 perspective
In an attempt to align the above terminology guidance with an HL7v3 messaging environment, the following recommendations apply:
(1) If a value is applied to a ‘Procedure’ or ‘Observable entity’ concept then it must be represented in an HL7 message in an Act.Observation, in the code attribute, with the value in
the value attribute. If context is explicitly stated, the ‘Procedure’ or ‘Observable entity’ concept will behave as a ‘finding’.
(2) If appropriate within the HL7 definition of a procedure, a ‘Procedure’ or ‘Observable entity’ concept may be used in the code attribute of an Act.Procedure (or any HL7 Act other than Act.Observation or its specialisation). Such Acts do not support the recording of a value attribute, so there cannot be a value. If context is explicitly stated, the ‘Procedure’ or ‘Observable entity’ concept will behave as a ‘procedure’. It is anticipated that an Act.Procedure will be used for representing Past Surgical History and Family Surgical History of procedures (rather than an Act.Observation that the procedure has been done).
(3) A ‘Procedure’ or ‘Observable entity’ concept may be used in the code attribute – without a value – in an Act.Observation, providing the Mood code of the Act is set to INT (intent) or one of its descendants. If context is explicitly stated, the ‘Procedure’ or ‘Observable entity’ concept will behave as a ‘procedure’, and will have a ‘procedure context’ value in the descent of 410522006: pre-starting action status.
Each ‘Context-dependent finding’ and ‘Context-dependent procedure’ record entry that is created this way should only be associated with one ‘associated finding’ or ‘associated procedure’ value. For example, the representation of ‘family history of hypertension and diabetes’ should be achieved by two separate concepts[2]:
And
Rather than a combined concept:
2 Additional context constraints
Once it is decided how a concept is to behave (whether as a ‘finding’ or as a ‘procedure’), the actual values for each context attribute must be set. As already stated, the values will depend upon a combination of:
• The nature of the modifying clinical assertion
• The placement of the concept within a record, document of message component
• Default context value settings
Table 4 and Table 5 summarise the context attribute-value settings for context modified concepts based upon the abstract qualifiable concepts ‘Context-dependent finding’ and ‘Context-dependent procedure’.
|Context-dependent finding |
| |Represented by ⋄ |
|Context modification to be |‘Finding context’ attribute|‘Temporal context’ |‘Subject relationship |
|represented ® |408729009: |attribute 408731000: |context’ attribute |
| | | |408732007: |
|Finding context (assertion |Select value in descent of |Set to soft default of |Set to soft default of |
|of risk, expectation, goal, |‘finding context value’ |‘current or specified’ |‘subject of record’ |
|presence/absence or |410514004 (exception * |410512000 |410604004 |
|unknown): |below) |(exception * below) | |
|Temporal context (assertion |Set to soft default of |Select value in descent of |Set to soft default of |
|of current or past time in |‘known present’ 410515003 |‘temporal context value’ |‘subject of record’ |
|relation to the finding) | |410510008 |410604004 |
|Subject relationship context|Set to soft default of |Set to soft default of |Select value in descent of |
|(assertion of relationship |‘known present’ 410515003 |‘current or specified’ |‘person’ 125676002 |
|between the subject of the | |410512000 | |
|record and the subject of | | | |
|the finding) | | | |
|* The above can be used in combination, with any ‘selected values’ over-riding soft defaults, except for the |
|following case, where ‘Finding context’ negation alters the ‘Temporal context’ default: |
|Assertion of ‘no past |Select value in descent of |Set to ‘all times past’ |Set to soft default of |
|history of finding’ |‘known absent’ (410516002, |410589000 |‘subject of record’ |
| |410594000 or 410593006) | |410604004 |
Table 4: additional context constraints for ‘Context-dependent finding’
|Context-dependent procedure: |
| |Represented by ⋄ |
|Context modification to be |‘Procedure context’ |‘Temporal context’ |‘Subject relationship |
|represented ® |attribute 408730004: |attribute 408731000: |context’ attribute |
| | | |408732007: |
|Procedure context |Select value in descent of |Set to soft default of |Set to soft default of |
|(assertion of unknown, |‘context values for |‘current or specified’ |‘subject of record’ |
|contraindicated, pre- and |actions’ 288532009 |410512000 |410604004 |
|post-starting statuses and |(exception * below) |(exception * below) | |
|not done): | | | |
|Temporal context (assertion|Set to soft default of |Select value in descent of |Set to soft default of |
|of current or past time in |‘done’ 385658003 |‘temporal context value’ |‘subject of record’ |
|relation to the procedure) | |410510008 |410604004 |
|Subject relationship |Set to soft default of |Set to soft default of |Select value in descent of |
|context (assertion of |‘done’ 385658003 |‘current or specified’ |‘person’ 125676002 |
|relationship between the | |410512000 | |
|subject of the record and | | | |
|the subject of the | | | |
|procedure) | | | |
|The above can be used in combination, with ‘set values’ over-riding soft defaults, except for the following |
|case, where ‘Procedure context’ negation alters the temporal default: |
|Assertion of ‘no past |Set to ‘not done’ 385660001|Set to ‘all times past’ |Set to soft default of |
|history of procedure’ | |410589000 |‘subject of record’ |
| | | |410604004 |
Table 5: additional context constraints for 'Context-dependent procedure'
As indicated above, context modified findings and procedures can therefore be constructed by the following steps:
• Identify how the non-context-modified concept will ‘behave’.
• Associate each concept with appropriate abstract context-dependent concept
• Identify attribute/value settings that will represent the required contextual modification. These can be selected independently except for the influence of finding or procedure negation on the temporal representation of ‘past’ – in this combination, the latter must be set to ‘all times past’ as opposed to any descendant of ‘past’.
• For un-modified context attributes, set the value to the ‘soft default’.
‘Archetypical’ example context-modified concepts following the guidance and constraints above are provided in the embedded .xml file in Appendix 2.
3 Close-to-user context modification
In the spirit of ‘close-to-user’ representation discussed elsewhere in this document, it would seem reasonable for the initial stored contextually modified data to reflect only those attributes and values where a non-soft-default value has been set. The ‘missing’ defaults (or contextually implied values) can be set during the Transformation from ‘close-to-user’ forms to normal forms (section 9.9 stage F).
4 Supplementary points
1 Rendering
Consistent with the post-coordinated concept rendering guidance offered in the Genesis document, the following recommendations are made. Systems should:
• Allow the communication, but not the presentation for rendering, of the concepts ‘Context-dependent finding’ and ‘Context-dependent procedure’.
• Allow the communication of ‘close-to-user’ representations, providing the recipient has no requirement for the normal form, or is able to perform the necessary transformation to a normal form.
For example, the concept ‘family history of kidney disease’ would previously have been represented as:
but can more economically be initially stored and communicated as:
and would be rendered as:
‘disorder of kidney, person in the family’.
Note: the transformation steps taking ‘close-to-user’ forms to comparable valid or canonical forms will ‘move’ the two un-grouped attribute-value pairs (associated finding=disorder of kidney, subject relationship context=person in the family) inside the required role group associated with the base concept ‘Context-dependent finding’. The exception will be the case of X without Y pattern concepts, where the context on X and Y will vary and, for example, prior specification of grouped associated finding/finding context will need to be made explicit at the time of recording.
7 Communication guidance
1. The primary rule for individual clinical communication is to stay as close to that entered and stored as possible. Additionally requirements of readable rendering are best served by avoiding the noise generated by including other unrefined attributes or unrefined sites when all sites are identically lateralised.
2. Where information is entered in a way that sensibly and explicitly distinguishes grouped characteristics (e.g. sites grouped with methods or morphologies), or sites that are individually lateralised (such as suggested in section 9.1.1 Input parts 2.d and 2.e) this associated information does need to be communicated.
3. Requirements for communication include the ability to (1) represent grouping between attributes and (2) the nesting of attributes within the values of other attributes. However, these facilities should only be used where these structures are required by the nature of the information as entered (not simply because a concept has role grouped relationships).
The same expression syntax (e.g. the used of HL7v3 data structures) can be used for communicating ‘close-to-user’ forms as is used for normal (or canonical) forms. The distinction between them is not the syntax but rather the completeness of the expression.
8 Retrieval and comparison guidance
1. Effective retrieval for decision support or analysis requires information to be available in a form that represents the semantics in a consistent manner. The SNOMED CT concept model – including the context model – provides a way to transform information between normal forms in ways that enable testing of equivalence and subsumption.
2. The SNOMED CT canonical form is designed specifically for this purpose and there are rules on how to transform from other valid forms to the canonical form. However, there are no rules as yet for transforming from close-to-author expressions. The rules suggested below (section 9.9 Transformation from ‘close-to-user’ forms to normal forms) provide a starting point for such rules.
3. The over-riding principle is that none of the rules for close-to-author expressions in any way negate the requirement for canonical forms. Thus any close-to-user form must either be 100% distinguishable from (and transformable to) a normal form or must be identical to the normal form in its representation and semantics.
9 Transformation from ‘close-to-user’ forms to normal forms
These rules are intended to be general, and should be usable to transform ‘close-to-user’ post-coordinated stored data into normal forms. The rules have not been fully tested, but a workable post-coordinated solution that can satisfy the multiple axes of interest described in the introduction is required if we are to avoid 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:
• 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).
If the rules are found to be erroneous, and this cannot be sensibly rectified, then this will require a fallback approach to post-coordination that is more rigorously adherent to the logical requirements of the distributed SCT data, often at the expense of the desirable characteristics previously identified.
Transformation should be achieved by applying the rule set laid out in Table 6 - Table 8 (clauses A-G). These rules use the following terms which are explained here and can also be related back to the content of Table 1: post-coordinated expression notation.
Expressions
[‘Close-to-user’-Expression: Whilst not used below, this would represent the stored Expression according to the post-coordination strategies suggested above.]
Input-Expression: for any iteration of the rules, the Input-Expression is that fragment of the ‘Close-to-user’-Expression that is undergoing transformation analysis.
Nested-Expression: although limited by the constraints of allowable post-coordination in SCT, any input expression may contain a Nested-Expression – that is, the value of an attribute (whether grouped or un-grouped) may be a valid expression in its own right [(V) or(Vg.n)] from Table 1.
Output-Expression: for each iteration of the rules, the Output-Expression will be the result of (1) a comparison between the distributed modelling and Input-Expression modelling and/or (2) a canonical form conversion for the Base concept [C] of the Input-Expression.
Temp-Expression: for each iteration of the rules, however generated, the Temp-Expression will be the substrate for canonical form conversion of the Input-Expression. Once converted, the canonical form will replace Temp-Expression until assigned as the Output-Expression.
Concept definitions and Expression modelling:
Base-concept: for any Input-Expression, the Base-Concept is that concept [C] which is defined, qualified or refined by any number of attribute value pairs.
Def-Base: the distributed definitions (in the most appropriate release of SCT for comparison) for the Base-concept of an Input-Expression.
Def-AVP: an attribute-value pair in Def-Base, whether grouped or un-grouped
Def-Grp: a group in Def-Base
Exp-AVP: an attribute-value pair in the Input-Expression. If, as a result of analysis, Exp-AVP is marked for inclusion, it will be included in the modelling of the Temp-Expression.
Exp-Grp: a copy of each Def-Grp that is created during the comparison between the distributed modelling and Input-Expression modelling. If, as a result of analysis, Exp-Grp is marked for inclusion, it will (along with the Exp-AVP’s it contains) be included in the modelling of the Temp-Expression. Otherwise it is discarded.
Exp-Ungrp: the collection of ungrouped attribute-value pairs that is identified as suitable for inclusion in the Temp-Expression during the comparison between the distributed modelling and Input-Expression modelling.
Each Input-Expression should be examined in the following way:
| |Does the Input-Expression contain any groups? |
| |YES |Treat the Input-Expression as a formal qualification of the Base-concept definition |
| | |Does the Input-Expression contain Nested-Expressions as the values of any attribute? |
| | |Examples may include: |
| | |Laterality nested within procedure site or finding site |
| | |Post-coordinated representation of an associated finding or associated procedure in a SNOMED CT context |
| | |dependent expression. |
| | |YES |For each Nested-Expression in the Input-Expression |
| | | | |Recursively apply rules starting at step-A. with the Nested-Expression applied as the |
| | | | |Input-Expression. |
| | | | |Replace the Nested-Expression in the original Input-Expression with the |
| | | | |Output-Expression from the recursive call. |
| | |Treat the Input-Expression (as modified) as the Temp-Expression. |
| | |Continue from step-D. |
| |NO |Continue from step-B. |
| |Take the distributed definition of the Base-concept as Def-Base and compare this with the Input-Expression as follows. |
| |Note: Use the distributed definitions for this process not the canonical table as the full set of defining relationships|
| |needs to be considered rather than the differences from proximal primitives. |
| |Does Def-Base include any groups? |
| |NO |Treat the Input-Expression as a formal qualification of the base concept definition |
| | |Does the Input-Expression contain nested expressions for any attribute value? |
| | |YES |For each Nested-Expression in the Input-Expression |
| | | | |Recursively apply rules starting at step-A. with the Nested-Expression applied as the |
| | | | |Input-Expression. |
| | | | |Replace the Nested-expression in the original Input-Expression with the |
| | | | |Output-Expression from the recursive call. |
| | |Treat the Input-Expression (as modified) as the Temp-Expression. |
| | |Continue from step-D. |
| |YES |Continue from step-C. |
Table 6: Transformation Clauses A-B
| |Compare Def-Base with the Input-Expression as follows: |
| |Create an empty Temp-Expression consisting of the Base-Concept from the Input-Expression with no additional |
| |qualifications. |
| |Process defined ungrouped attribute value pairs as follows |
| |Create Exp-Ungrp as an empty collection of ungrouped attribute value pairs. |
| |For each Def-AVP in the ungrouped attribute-value pairs of Def-Base |
| | |For each Exp-AVP in the attribute value pairs of the Input-Expression. |
| | | |Is Exp-AVP marked as included? |
| | | |NO |Is Exp-AVP subsumed by Def-AVP? |
| | | | |Note that there are several possible types of AVP subsumption |
| | | | |Same attribute name and subsumed value |
| | | | |Same attribute name and same value with nested qualifier |
| | | | |Subsumed attribute name and same value |
| | | | |Subsumed attribute name and subsumed or qualified value |
| | | | |YES |Mark Exp-AVP as included. |
| | | | | |Add to Exp-AVP to Exp-Ungrp |
| | | | |NO |Is Exp-AVP an assertion of laterality and Def-AVP a lateralisable site? |
| | |
| |For each Def-Grp in the relationship groups of Def-Base |
| | |Create Exp-Grp as a copy of Def-Grp |
| | |For each Def-AVP in the attribute-value pairs in Def-Grp |
| | | |For each Exp-AVP in the attribute value pairs of the Input-Expression. |
| | | | |Is Exp-AVP subsumed by Def-AVP. |
| | | | |Note that there are several possible types of AVP subsumption |
| | | | |Same attribute name and subsumed value |
| | | | |Same attribute name and same value with nested qualifier |
| | | | |Subsumed attribute name and same value |
| | | | |Subsumed attribute name and subsumed or qualified value |
| | | | |YES |Add Exp-AVP to Exp-Grp. |
| | | | | |Is Def-AVP still present in Exp-Grp? |
| | | | | |Note it may not still be present if removed by another subsumed attribute value pair. |
| | | | | |YES |
| | | | | |Mark Exp-Grp for inclusion |
| | | | |NO |Is Exp-AVP an assertion of laterality and Def-AVP a lateralisable site? |
| | | |
| | |YES |Add Exp-Grp to the Temp-Expression |
| |Process attribute value pairs in Input-Expression that are not included |
| |Note: These are unsanctioned qualifiers for the Base-Concept in the release of SNOMED CT used for computing earlier |
| |steps. |
| |For each Exp-AVP in the attribute value pairs of the Input-Expression. |
| | |Is Exp-AVP marked as included? |
| | |NO |Add Exp-AVP to Exp-Ungrp |
| |Does Exp-Ungrp contain any attribute value pairs? |
| |YES |Add Exp-Ungrp to Temp-Expression |
| | |By convention this is inserted after the Base-Concept and before the first group. |
Table 7: Transformation clause C
| |Convert the Temp-Expression to its canonical form using rules documented elsewhere. [TIG Appendix F] |
| |Note: At this point the Temp-Expression is now a valid form (e.g. all grouping is in place) so it can be converted to |
| |its canonical form. In practice it might be possible to do the canonical conversion alongside the steps in C. However, |
| |the disadvantage of this are that it would require different algorithms for computation compared with items that start |
| |with a valid close-to-user expression (e.g. cases covered by A. and B.) |
| |Was the Input-Expression a Nested-Expression from a recursive call? |
| |YES |Assign the Temp-Expression as the Output-Expression. |
| | |E.g. for replacement in the appropriate place in the higher level process. |
| | |RETURN Output-Expression to calling level |
| |Is the Base-Concept a subtype of context dependent concept? |
| |NO |Create a new Output-Expression based on a context dependent concept with appropriate context attributes |
| | |defined as follows: |
| | |Apply context implied by surrounding structure (e.g. HL7v3 moodCode). |
| | |Apply any other context attributes according to SNOMED CT soft default rules. |
| | |Nest the Temp-Expression within the created Output-Expression as the "associated finding" OR "associated |
| | |procedure" according to whether it is procedure or observable without a value (procedure) or a clinical |
| | |finding (finding) or a procedure or observable with a value (finding). |
| |YES |Are all required context attributes present? |
| | |NO |Add additional context attributes to the Temp-Expression |
| | | |Apply context implied by surrounding structure (e.g. HL7v3 moodCode). |
| | | |Apply any other context attributes according to SNOMED CT soft default rules. |
| | |Assign the Temp-Expression as the Output-Expression. |
| |RETURN Output-Expression. |
Table 8: Transformation clauses D-G
1 Comments on transformed forms
The results of the transformations are intended to be used for reference purposes in retrieval. They need to be recomputed for each release of SNOMED CT, and are not appropriate as a substitute for the ‘close-to-user’ form. There are various strategies for when to apply the computation:
o In real time during retrieval (probably only suitable for small scale use)
o When SNOMED CT updates are received as a type of re-indexing of the original data.
o When SNOMED CT updates are received, and applied to a reference table of identified nodes in which each ‘close-to-user’ expression exists only once with its translation to the transformed form. Application of a classifier to this table to generate an acyclic graph for all used nodes would then simplify retrieval – since only simple subsumption tests are required.
.
10 Transformation risks
The principal risk of a standard solution to post-coordination based on the rules presented in section 9.9 (Transformation from ‘close-to-user’ forms to normal forms) is that it will not behave as intended, and result in un-predictable or incorrect canonical forms.
Such an approach to post-coordination is relatively recent, and therefore has not yet been adequately tested. Main consideration has been given to laterality, site and contextual modification so far, but the intention would be that such an approach would be applied to post-coordination for all sanctioned characteristics.
Note: systematic testing of the ‘close-to-user’ approach, and its transformation to comparable valid and canonical forms is being organised.
Appendix 1
1 Defining and qualifying characteristics
Table 9 lists the concept model attributes (in the descent of 410662002), and indicates whether systems needs to allow them to participate in any form of post-coordination (note that these are settings agreed for the January 2005 data). As will be seen, some concept model attributes participate in both defining characteristics (D) and qualifying characteristics (Q). There is potentially some confusion around the terms and definitions used to identify the refinability rules [TRG p85], which the following explanation should help to clarify:
The Technical Reference Guide states that, for a given defining or qualifying characteristic:
Not refinable = Not refinable
Mandatory to refine = Must be refined by selecting a subtype.
Optional to refine = May be refined by selecting subtypes
A fuller explanation indicates that the meaning depends on whether the relevant attribute is defining or qualifying, and whether a defining characteristic is to be stored (un-modified) to satisfy the requirements of a role group:
For a defining attribute it can be said that:
• It cannot be refined – Not refinable. This should only be used where an attribute cannot rationally be refined. Whilst some of the not refinable assertions in Table 9 might be thought of as too stringent, they have been selected to try and rationalise post-coordination for current use.
• It can be refined
o At present this is classified as mandatory to refine - the historical reason being that a characteristic would not be stated unless it were being refined (there would be no need to record the procedure site ‘appendix’ for an ‘appendicectomy’ if this was already asserted in the reference data). This is generally true of a defining attributed but it does cause confusion for two reasons.
1. In some cases it applies where there is no possible refinement at present (leaf values). This is acceptable, and is managed by the inevitable limit on allowable refinement for any SCT release.
2. In other cases an un-refined value may need to be restated in a role group (where a co-grouped characteristic has been modified and the persistence of the grouping is important for concept meaning). This is acceptable given the requirements of role grouping.
For a qualifying attribute it can be said that:
• It cannot be refined - Not refinable. This would mean that a qualifier could only be selected as stated in the table row (note: there is currently no data of this form)
• It can be selected and used unrefined – Optional to refine. For example, ‘Onset=Onsets’ can be selected without refinement, since qualifying rows exist in the table that are valid without refinement
• It must refined if it is selected – Mandatory to refine. For example, if Laterality=Side’ and ‘Severity=Severities’ are used, the value actually selected must be a sub-type of the general (and clinically unhelpful) value organising concepts ‘Side’ and ‘Severities’.
|Concept model attribute |Refinability rules: |
|(descendants of 410662002) | |
| |Refinable? |If refinable |
| |(⎦=not refinable) |(D=defining, Q=qualifier): |
| | |Mandatory |Optional |
|├─ access instrument | |D | |
|├─ access | |DQ | |
|├─ approach | |D |Q |
|├─ associated finding | |D | |
|├─ associated morphology | |D | |
|├─ associated procedure | |D | |
|├┬ associated with |⎦ | | |
|│├─ after |⎦ | | |
|│├─ causative agent | |D | |
|│└─ due to |⎦ | | |
|├─ component |⎦ | | |
|├─ course | |DQ | |
|├─ direct substance | |D | |
|├─ episodicity | |DQ | |
|├─ extent (not approved) |⎦ | | |
|├─ finding context | |D | |
|├─ finding site | |D | |
|├─ has active ingredient |⎦ | | |
|├─ has definitional manifestation |⎦ | | |
|├─ has dose form |⎦ | | |
|├─ has focus |⎦ | | |
|├─ has intent |⎦ | | |
|├─ has interpretation |⎦ | | |
|├─ has specimen |⎦ | | |
|├─ interprets |⎦ | | |
|├─ laterality | |DQ | |
|├─ measurement method |⎦ | | |
|├─ method | |D | |
|├─ occurrence |⎦ | | |
|├─ onset | |D |Q |
|├─ part of |⎦ | | |
|├─ pathological process |⎦ | | |
|├─ priority | |DQ | |
|├─ procedure context | |D | |
|├┬ procedure device | |D | |
|│├─ direct device | |D | |
|│├─ indirect device | |D | |
|│└─ using | |D |Q |
|├┬ procedure morphology | |D | |
|│├─ direct morphology | |D | |
|│└─ indirect morphology | |D | |
|├┬procedure site | |D | |
|│├─ procedure site – Direct | |D | |
|│└─ procedure site – Indirect | |D | |
|├─ property |⎦ | | |
|├─ recipient category |⎦ | | |
|├─ revision status | |D | |
|├─ scale type |⎦ | | |
|├─ severity | |DQ | |
|├─ specimen procedure |⎦ | | |
|├─ specimen source identity |⎦ | | |
|├─ specimen source morphology |⎦ | | |
|├─ specimen source topography |⎦ | | |
|├─ specimen substance |⎦ | | |
|├─ subject of information (under review) |⎦ | | |
|├─ subject relationship context | |D | |
|├─ temporal context | |D | |
|└─ time aspect |⎦ | | |
Table 9: Refinability rules for concept model attributes
Appendix 2
1 Archetypical contextual modification
The following embedded document shows a number of archetypical contextually modified concepts according to the guidance given in this paper. The embedded document is in a simple .xml form, organised thus:
= root element
= element to separate each ‘archetypical’ example, with the example variety as the value of the name attribute.
… etc. with groups and qualifiers – using the same quasi-HL7v3 CD data type notation as examples elsewhere. Note examples inlcude the soft default values for the un-modified axes.
and
= indicate the presence of a finding, procedure or observable entity concept (depending on behaviour).
[pic]
-----------------------
[1] Note – ‘link assertion’ concepts have a specific intended use (for the representation of judgemental assertions between clinical statements) in UK NHS National Programme for IT specifications. More detailed guidance on their use is published in the document P1R2 Messaging Technical Guidance.
[2] This solution will present problems for ‘X without Y’ pattern concepts, but should be suitable for the majority of post-coordinated concepts. Recommendations will need to develop to support such patterns.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- doc ieee 802 11 11 0316r0
- overview of a semantic web and multi agents approach to
- odata json format for common schema definition
- the semantic novelty of theoretical terms
- doc ieee 802 11 09 1034r12
- metric template
- definition of the cidoc conceptual reference model
- sct postcoordination
- title guidelines for authors of `approaches to discourse