Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A terminology server supporting postcoordination should support the general features of a SNOMED CT-enabled terminology server, and additionally, support the features required to manage and use postcoordinated expressions. This involves an expression repository to store the postcoordinated expressions, and a set of services to access, process and query the expressions in the same way as pre-coordinated SNOMED CT content. This section provides an overview of the general requirements of an expression repository and the associated services.
The logical design of an expression repository includes the entities required to hold the data relevant for an expression version.
The image in this page illustrates an expression repository contains one or more expression versions.Each expression version must contain the following data:
Versioning data , to represent the time and substrate of the given version of the expression
A Close-to-user form expression , to represent the expression as it was stated upon creation
Each expression version should contain the following data:
An expression identifier , if this is required to uniquely identify the expression
A Classifiable form expression , to enable the generation of the NNF expression
A Necessary Normal Form expression , to support querying the expression
All SNOMED CT concepts referenced by expressions in the repository at a particular point in time should all be included, and active, in a specific versioned edition of SNOMED CT. General expression repository design.
The table below provides an overview of key requirements for an expression repository. Additional requirements may be relevant for certain use cases, and this overview should, therefore, be used as a minimum set. The definition of the terms used in this table can be found below.
This page introduces the users, use cases and resulting service requirements for a terminology server supporting postcoordination.
Expression Repository Users
The tables below shows the set of services will enable users interacting with an expression repository to perform required tasks.
Classifiable form expression
The expression repository should store the expression in a form that can be used as input to the classifier when generating the necessary normal form
Optional
Necessary normal form expression
The expression repository should store the expression in a form that is suitable for querying
Optional
Expression id
The expression repository should store a unique identifier that can provide an easy reference to the expression
Optional
Effective Time
The expression repository must store an effective time for each version of an expression. Although the CTU will never change, the CF and NNF may.
Mandatory
Substrate
The expression repository must include a reference to the SNOMED CT content used to generate the expression.
Mandatory
The following three expression forms may be supported by the expression repository:
Close-to-user form
The CTU represents the expression as it was entered or created
The CTU is the primary stored and communicated view of the expression
The CTU is immutable, i.e. it will not change even though the repository is updated to new versions of SNOMED CT
Classifiable form
The CF expression is a syntactically valid and concept model compliant representation of the close-to-user form expression
The CF serves as the input to the classifier, enabling expressions to be classified together with other SNOMED CT content
The CF may change when an expression repository is updated to a new version of SNOMED CT
Necessary normal form
The NNF is the output of classifying the CF expression with a given SNOMED edition
The NNF represents the necessary relationships used for querying, so this becomes part of your substrate when you’re running an Expression Constraint query
The NNF includes refinements representing inferred relationships, without any redundant refinements or relationship groups
When included, the CTU, CF, and NNF should be stored in the expression repository in their canonical form. The canonical form is produced by applying a set of rules to the SNOMED CT expression to ensure a single unique representation of the expression.
The expression repository should support the unique identification of all expressions in the expression repository. The Canonical Close-to-user Form of an expression may be used to identify itself, but some implementations may require the storage of a fixed length, unique identifier for expressions used in an operational environment.
Some clinical systems have a limitation on the number of characters that can be used to identify clinical meanings in their databases. In systems that limit the length of these clinical meaning representations to 18 digits or less, postcoordinated expressions that are longer than this must be stored using a globally unique and unambiguous identifier containing 18 digits or less. A maximum of 18 digits is considered appropriate for this requirement, as this is the maximum length of standard SNOMED CT concept identifier. Therefore, any clinical system which supports SNOMED CT precoordinated concepts must support this number of characters.
The expression repository should support version history. Although there will only ever be one version of the CTU, there is likely to be many versions of the CF and NNF over time. Versioning is therefore required to allow lookup and analysis of previous versions of expressions. This involves the representation of the effective time and the substrate.
For each version of an expression, the date should be recorded to enable the lookup of an expression for a particular point in time.
For each version of the expression, the substrate used to generate the expression should be stored.
The substrate is the SNOMED CT content used for creating the expression. Because medical knowledge is constantly changing, and SNOMED CT evolves to reflect these changes, the concepts used to create an expression may be impacted over time. Therefore, it is important that the substrate is kept current to ensure that the meaning of the expression can be interpreted. With this in mind, both the SNOMED CT edition and the specific version of that edition (released on a given date) need to be included when determining the SNOMED CT substrate for an expression.
The SNOMED CT URI Standard defines a common format of URIs for identifying various SNOMED CT artefacts, including components and RF2 releases. This includes URIs for formally identifying the SNOMED CT international edition, national editions, and any specific versions thereof and can, therefore, be used to represent the substrate for the repository.
Close-to-user form expression
The expression repository must store the expression as it was entered by the user
Mandatory
Create expression repository
Should be able to retrieve details about the expression repository to enable referencing the content of this specific expression repository, e.g. for adding and updating content in the expression repository.
Get repository details
Should be able to add expressions to the repository when these are created prior to the implementation within an EHR
Add expression
Should be able to check if an expression constraint conforms to the concept model rules
Validate expression
Should be able to check if expressions exists in the repository, e.g. as part of exploring if new expressions should be created
Lookup expression
Should be able to view the details of each expression in the expression repository
Lookup expression
Should be able to search for expressions using term search
Search for expression
Should be able to retrieve expressions matching specific search criteria, e.g. as part of bulk edit features, expression reviews, etc.
Query expressions
Should be able to update expressions in an expression repository to enable correction of errors or to support updates to a new substrate
Update expression
Should be able to disable or inactivate expressions that are no longer recommended for use
Inactivate expression
Should be able to add expressions to the expression repository, e.g.when the EHR supports runtime creation of expressions using form-based data entry
Add expression
Should be able to see a term for an expression, e.g. when this is rendered as an option in a clinical user interface
Get display term
Should be able to search for expressions using text-based search, e.g. when expressions are included in a value set bound to a search field
Services should be available to support the creation of an expression repository, involving the creation of the structures required to hold the data of the expression repository, as described in Expression Repository Requirements. These services are required to provide an 'empty' expression repository.
Services should be available for getting details about a generated expression repository. The details can be used when accessing content of this specific expression repository, e.g. when adding, updating or querying expressions.
Services should be provided to support the addition of new expressions to the expression repository. These services should ensure that all data required to represent and process expressions are available.
Services for adding expressions will often include the services for validating the expression, transforming the expression and generating the necessary normal form.
Services should be provided to support transformation of the close-to-user form expression to a classifiable form which is required to generate the necessary normal form.
Considerations and approaches to transformation are described in Implementation.
Services should be available to check if the close-to-user form of the expression is syntactically valid and conforms to the concept model rules, or any allowed rules for postcoordination.
Services should be provided to support the generation of the necessary normal form of the expression, which is a prerequisite for supporting expressions to be queried in the same way as pre-coordinated content.
Considerations and approaches to the generation of the necessary normal form are described in Implementation.
Services should be provided to support the updating of expressions while retaining full traceability of previous versions of the expression (similarly to the principles of updating precoordinated SNOMED CT content).
Services should be provided to support the indication that an expression is no longer recommended for use. Although inactivated, the expression should be retained in the repository and full traceability of previous versions (similarly to the principles of inactivating precoordinated SNOMED CT content).
Services should be provided to support access to details about the individual expressions in the repository.
Services should be provided to support searches for expressions in the repository. Lexical searches should be supported based on the terms associated with the concepts included in the expression.
Services should be provided to support a human-readable representation of the expression. This service is required to enable the display of expressions in user interfaces, or to support term searching.
Services should be provided to test the subsumption relationship between a pair of expressions given the semantics of subsumption
Services should be available to enable subsumption testing between expressions and enable the selective retrieval of postcoordinated expressions satisfying stated criteria. Query services should enable queries to be performed over the content of a specific expression repository plus the content of the versioned edition of SNOMED CT that the repository depends on.
Information Manager
This user represents the people involved with the implementation of SNOMED CT-enabled systems and the maintenance of postcoordinated expression repositories
This user group interacts with an Expression Management System, designed to support key tasks required to create and maintain postcoordinated expressions in an expression repository
Clinical user
This user represents the people involved with the entry of clinical data in an EHR system (or another type of clinical information system)
This user represents the people involved with the entry of clinical data in an EHR system (or another type of clinical information system)
Should be able to set up the expression repository when preparing for an implementation
For each CTU, there will be one NNF
Search for expression
Should be able to store expressions in the EHR data store
Add expression
Should be able to share details about an expression, e.g. to support communication and exchange
Lookup expression
Should be able to query expressions in the same way as pre-coordinated concepts to support tasks such as reporting, clinical data analysis and decision support
Query expressions
To enable postcoordination within electronic health records a terminology server is required that provides the services needed to validate and process expressions.
The terminology services required for postcoordinated expressions are similar to the ones used when authoring content within a published SNOMED CT edition.
When submitting postcoordinated expressions to a terminology server, the expressions can be seen as a derivative, or a supplement, to the SNOMED CT Edition content available in the terminology server. Postcoordinated content lives alongside and can only be interpreted or understood in the context of a specific SNOMED CT Edition version.
Because of the dependency on a versioned SNOMED CT Edition, the successful implementation of expressions involves services to continuously ensure validity and traceability. Similar to the approach to creating SNOMED CT extensions containing clinical concepts, postcoordinated expressions, therefore, need to follow the general principles for extensions, including validation, classification, and versioning.
As illustrated in the image below, the terminology server should, therefore, be designed to hold the given versioned SNOMED CT Edition, and an expression repository to hold the postcoordinated expressions. Furthermore, in addition to the services required by the EHR to use the content and derivatives of released SNOMED CT Editions (see Terminology Services Guide), services are required to support the use of the postcoordinated content.
The following pages will elaborate on the requirements, overall design, and implementation of a SNOMED CT-enabled expression repository, and present the services needed for supporting expressions in a terminology server.
This guide does not mandate a particular way to meet the requirements and the design of an expression repository as outlined in Requirements and Design. However, to ensure that terminology servers supporting postcoordination are implemented in a way that doesn't compromise terminological integrity and clinical safety, this section presents considerations important for the implementation of an expression repository. Also, different approaches to implementations are be presented.
When implementing a terminology server supporting postcoordination with SNOMED CT, careful considerations must be taken to ensure that the approach taken doesn't compromise safety. As a combined effort between the terminology server and the client, the following criteria for expressions must, therefore, be ensured:
All expressions should conform to the concept model when represented in their classifiable form
No ambiguity is allowed, i.e. the transformation of the expression into its classifiable form must not result in a modification of the intended meaning of the expression
Meeting these criteria can be done in several ways and depends on the responsibility taken by the terminology server and client respectively.
Each terminology server designed to enable postcoordination with SNOMED CT should clearly specify the level of transformation supported, to enable requirements to be specified for the client side, and to support decisions about the use of postcoordination for the specific implementation. The diagram below illustrates four levels of support for postcoordination. At each level, the sum of restrictions provided by the terminology server and the client must ensure that the criteria for 'safe' postcoordinations are met.
Level 0
The terminology server will classify the expression without transformation.The client is responsible for ensuring that expressions are fully MRCM-compliant.
CTU should be fully MRCM compliant
Same as CTU
Implementation Examples
The following pages provides examples of how specific terminology servers support the implementation of expression repositories.
Level 1
The terminology server behaves as in level 0 if the expression is fully MRCM compliant. The terminology server will apply transformations based on known close-to-user form patterns to generate the classifiable form.The client is responsible for ensuring that expressions are fully MRCM-compliant or conform to allowed close-to-user form patterns.
CTU should be fully MRCM compliant or conform to close-to-user form patterns
Generated by transformation
Level 2
The transformation logic for these levels has not yet been agreed. At this stage, postcoordinations and transformation logic beyond the patterns described at level 1 are, therefore, not recommended.
N/A
Level 3
N/A
N/A
N/A
At this level, the terminology server requires all submitted expressions to already be in valid classifiable form. This form is a syntactically valid and concept model compliant representation expression that can be directly used as input to the classifier, enabling expressions to be classified together with other SNOMED CT content.
To enable postcoordination at Level 0, it is important that the system used to create the expressions supports any transformation needed to represent the expressions in their classifiable form. This may be enabled using one of the following techniques:
Form-based Creation
Expression Templates
These techniques will support the creation of expressions that fully comply with the concept model rules and avoid some of the common mistakes created. For example using attributes that are incorrect for the domain or incorrectly grouped.
Consider the situation where the following expression is created to represent the meaning of a "Disorder of left lung":
At level 0, this expression would not be accepted by the terminology server, because the MRCM only permits those concepts that are both within the << 91723000 |Anatomical structure (body structure)| domain and also listed in the to be qualified using . The focus concept of the expression is neither.
As a result of this rule, the action required to make the expression classifiable, is to add a nested expression where the laterality is applied to the value of the attribute that is part of the NNF for the same focus concept, , as follows:
Consider the situation where the following expression is created to express the meaning of a "Procedure on left lung":
At level 0, this expression would not be accepted by the terminology server, because is specified as being 'grouped', which requires a role group to be explicitly stated. As a result of this rule, the action required to make the expression classifiable, is to place the attribute in a group, as follows:
Terminology servers at level 0 will reject any expressions not conforming to the classifiable form.
The table below provides examples of a set of expressions with an indication of their acceptability and potential issues at level 0.
=== 19829001 |Disorder of lung (disorder)| : 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|=== 19829001 |Disorder of lung (disorder)| : { 363698007 |Finding site (attribute)| = ( 39607008 |Lung structure (body structure)| : 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)| )}=== 71388002 |Procedure (procedure)| : 363704007 |Procedure site| = 44029006 |Left lung structure (body structure)|=== 71388002 |Procedure (procedure)| : { 363704007 |Procedure site| = 44029006 |Left lung structure (body structure)| }: { = }
Yes
Although this expression complies with the concept model rules, the expression will not classify as probably desired, as a subtype of The reason for this is that the stated group does not include the required attribute: =
=== : =
No
Attribute does not apply to the domain | Malignant melanoma of shoulder|
=== : { = , = }
Yes
=== : { = , = ( : = )}
Yes
=== : = ( : = )
No
Attribute should be in a group
=== : =
No
Attribute should be in a group
This part of the guide introduces the design features of a terminology server supporting postcoordination with SNOMED CT.
This design meets the requirements outlined in and includes:
This page summarizes the implementation of an Expression Extension using the HL7 FHIR Terminology Services API. This approach is in the process of being implemented and supported by the Snowstorm FH
Under development
This section is still under active development, and the API examples will change as reference implementations mature and this is discussed with the community of practic
To represent an expression repository using FHIR terminology services, the required solution will depend on what approach is taken to uniquely refer to the expressions:
The expressions themselves may be used as an identifier
With this approach, a CodeSystem Supplement will be created and function as the expression repository
This supplements the applied SNOMED CT CodeSystem
A separate identifier is created for each expression
With this approach, the following FHIR are required
a to function as the expression repository
With this implementation, the defined operations for CodeSystems and ConceptMaps can be utilized to support the services required for an expression repository. Please refer to the HL7 FHIR documentation for further details:
CodeSystem
Creating an expression repository using a FHIR Terminology Server involves the creation of the following structures:
A (expRep): This functions as the actual expression repository and is used to hold the expressions
A (expId): This code system is used to hold the unique expression identifiers
A : This is used to map between the expressions in the expRep CodeSystem supplement and the expId CodeSystem. The ConceptMap enables the translation of expressions to (and from) shorter codes for systems with restricted code lengths
(Source: )
Use an implicit value set with ECL.
A display term should be returned in the response of the lookup operation. The display term may be generated in a very simple way by just concatenating.
This should happen when the expression is inserted into the code system.
This should happen when the expression is inserted into the code system.
a to hold the expression identifiers
a to hold the association between the expression identifiers and the expressions
ConceptMap
Create Code System Supplement
POST /CodeSystem
Create the CodeSystem supplement.
This operation must specify a version URI that uses the snomed.info xsct URI with a specific module but no version.
This resource must supplement a specific version of a SNOMED CT edition.
The example supplements the International Edition of SNOMED CT (900000000000207008), version Jan 2023 (20230131).
{
Create SNOMED Exp IDs Code System
POST /CodeSystem
(Only needed if EHR cannot store expressions)
If needed, create a CodeSystem for expression identifiers.
GET /CodeSystem/{id}
Get the details of the Code System using the provided ID; it is the same operation for the supplement or the Exp. IDs code system.
PATCH /CodeSystem/{id}
Adds an expression in the Code System Supplement using a patch operation.
The display value can be generated from the expression, or the expression itself could be used in this field.
This operation should run validation on the expression being inserted into the supplement.
GET /CodeSystem/{supplementId}/$lookup?code={CTU}
GET /CodeSystem//$lookup?system={versionUri}&code={CTU}
Lookup Expression in the supplement
versionUri
CTU: close-to-user expression
Expression subsumption test
GET /CodeSystem/$subsumes
Test the subsumption between a pair of expressions or an expression and a code.
{
Create Concept Map for Exp Ids
POST /ConceptMap
(Only needed if EHR cannot store expressions)
Create the ConceptMap to map expressions in the code system supplement to expression identifiers in the Exp. Ids code system. This will be populated manually.
GET /ConceptMap/{snomed-exp-id-map}/$translate?system={versionUri}&code={CTU}
Example
GET /ConceptMap/snomed-exp-id-map/$translate?system=http://snomed.info/xsct/1234007
&code=87971000:272741003=7771000
Lookup Expression Identifier from Expression
versionUri
CTU: close-to-user expression
GET /ConceptMap/{snomed-exp-id-map}/$translate?
reverse=true&system={versionUri}&code={expId}
Example
GET /ConceptMap/snomed-exp-id-map/$translate?
reverse=true&system=http://snomed.info/snomed/exp-id/1101234&code=101101234165
Lookup Expression from Expression Identifier
versionUri
expId: expression identifier as defined pr. implementation
"resourceType": "CodeSystem",
"url": "http://snomed.info/info",
"version": "http://snomed.info/xsct/11000003104",
"content": "supplement",
"supplements" : "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/20230131"
}Code System ID, provided in the response of the code system creation[
{
"op": "add",
"path": "/concept",
"value": {
"code": "359817006 |Closed fracture of hip (disorder)| :
272741003 |Laterality (attribute)| = 182353008 |Side (qualifier value)|",
"display": "Right closed fracture of hip"
}
}
] "resourceType": "CodeSystem",
{
"resourceType": "CodeSystem",
"url": "http://snomed.info/snomed/exp-id/1000003",
"status": "active",
"content": "complete"
}{
"resourceType": "ConceptMap",
"url": "http://snomed.info/snomed/exp-id-map",
"status": "active",
"source": {
a0 a0 a0 a0"sourceUri": "http://snomed.info/xsct/1234007?fhir_vs"},
"target": {
a0 a0 a0 a0"targetUri": "http://snomed.info/snomed/exp-id/1101234?fhir_vs"}
}Interacting with a terminology server is done via a set of supported services designed to meet key user requirements. The following pages provide details about the services required for a terminology server supporting postcoordination. Please note that the services designed to support an expression repository will often be used in conjunction with the services available to access precoordinated content. The general services of a SNOMED CT-enabled terminology server can be found in the Terminology Services Guide.
The objective of services for creating an expression repository is to set up the structures of the expression repository and provide an 'empty' expression repository.
To set up an expression repository, it requires a terminology server with access to a SNOMED CT versioned edition. This is important because all concepts referenced by an expression must be interpreted in the context of a specific SNOMED CT Edition. To support processing of the expressions, access to information about the source concepts and to the particular version of the MRCM that is encoded within the version of the substrate is needed.
Note the MRCM does not change very frequently: several different consecutive versions of the substrate will contain different sets of concepts and their stated relationships, but may contain essentially the same MRCM content and version.
In addition to specifying the 'substrate' of the expression repository, it is important to specify the primary language, or languages, that should function as the default language for the repository. This is important to support the display of terms associated with the expressions. For the language configuration, it is recommended to specify which language reference set(s), available in the substrate, should be used as the default.
To retrieve details about a generated expression repository. The details of the repository can be used when referring to the content of this specific expression repository, e.g. for adding and updating content in the expression repository.
The objective of a service to update an expression repository is to support the ongoing maintenance and alignment with new versions of SNOMED CT used as the substrate for the expression repository.
Updating an expression repository involves changing the substrate of an expression repository to a new, or another, substrate. Often, the new substrate will be to a new version of the expression repository substrate. Any changes made to the terminology between the SNOMED CT version being the current substrate and the SNOMED CT version that will become the new substrate may impact the content of the expression repository. For example, if a concept included in one of the expressions stored in the repository has been made inactive, the expression is no longer valid after applying the new substrate. Or, if concept model rules stated in the Machine Readable Concept model have been modified, expressions may no longer be concept model compliant.
The services for updating of the expression repository needs, therefore, need to support
Validate the CTU of all existing expressions against the new substrate
Resolve any validation issues, e.g. by
replacing inactive concepts with proper replacements
adjusting expression to conform to the MRCM
The objective of the services described in this page is to enable the addition of a new expression in the expression repository.
Adding an expression to an expression repository requires the validation of the expression and the storage of the expression as it has been entered by the user with the additional data and expression forms that are needed for subsequent access and use.
The logical process of the add expression service is illustrated in the diagram below.
The objective of this service is to validate a CTU expression and transform it into a classifiable form (CF) which can be used as input to the Description Logic classifier.
This service involves both the validation and transformation of a CTU expression. Three types of validation are required, including syntactic validation, content validation, and MRCM validation. For expressions not fully compliant with the MRCM, a transformation is required to generate the classifiable form.
The syntactic validation is performed to determine if the expression conforms to the SNOMED CT compositional grammar syntax (see section Parsing).
Please refer to the (section Validating) for more details on the validation of expression, and the for details on the computer processable concept model rules.
The content validation is performed to determine if all concept references included in the expression exists and are active in the version and edition of SNOMED CT which is the substrate for the given expression repository.
The MRCM validation is performed to determine if the expression complies to the concept model rules as expressed in the SNOMED CT Concept Model and specified by the machine readable concept model (the version of the MRCM applying to the version and edition of SNOMED CT which is the substrate for the given expression repository)
An expression that does not conform to the concept model cannot be relied upon to correctly classify. Therefore, it cannot be reliably tested for subsumption by another concept or inclusion in (or exclusion from) the results of an expression constraint or analytics query.
Specific terminology services required to support MRCM validation are described in the general Terminology Services Guide here: SNOMED CT concept model
Expressions that are fully compliant with the Machine Readable Concept will not need a transformation to be represented in the classifiable form. This means that for fully MRCM compliant expressions the close-to-user form and the classifiable form of the expression are the same.
An expression may be invalid when tested against the concept model but may contain refinements that would be valid if correctly structured. There are several situations where predictable structural adjustments enable a valid expression to be constructed from an informal expression that does not fully conform to the concept model.
Examples include:
Moving a loose attribute to an attribute group in which it is valid
Moving a loose attribute so it provides a nested refinement to the value of another attribute
A loose attribute is an attribute that is included in the refinement of an expression without being placed in a group, although the concept model rules require it to be grouped.
The extent to which a terminology server supports the transformation of non-MRCM compliant expressions into MRCM-compliant expressions may vary between terminology servers. Each terminology server should, therefore, clearly state the level of transformations supported for expressions that are not fully MRCM compliant. A recommended practice for this it to support an API call by which it is possible to determine the transformation level. For more detail on these levels, see
The logical process of the service to transform and validate an expression is illustrated in the diagram below.
Summary
Objective
The objective of this service is to support classification and Necessary Normal Form generation
Related Use Cases
Classification is required to enable the following use case: Query Expressions
Description
To enable postcoordinated expressions to be queried in the same way as pre-coordinated SNOMED CT concepts, the necessary normal form of the expression is required, as illustrated in the diagram below.
Workflow
Summary
Objective
The objective of this service is to get data associated with an identified expression.
Description
Services for retrieving data associated with an expression rely on an input pointing to the expression of interest. For this purpose, a unique identifier associated with the expression within an expression repository should be input to this service. If the CTU of the expression itself is used to uniquely identify the expression, this will be used for the lookup. If multiple versions of the expression exists, the service will return the most recent version of the expression.
Workflow
Objective
The objective of this service is to enable text-based searching for expressions in the expression repository.
Description
As specified in , an expression repository includes the canonical form of the stored expressions. The canonical form excludes any terms associated with the referenced concepts.Consider storing a term associated with the expression to aid searching.Please note that this guide does not include guidance on the storage of a human-readable term for expressions, but it recommends implementing services to automatically generate a display term. Some implementations may choose to store an autogenerated display term for each expression in the repository as part of adding the expression. This may be chosen to support easy lookup of the terms associated with the expressions to support services for searching.
Summary
Objective
The objective of services to get a display term for an expression, is to support the automatic generation of a term that can be used for the human-readable representation of the term, e.g for display or exchange.
Description
Three different approaches to automatically creating display terms for postcoordinated expressions is presented, ranging from the simplest to the most complex.
Replace concept identifiers with terms
Apply simple term rules
Apply description templates and rules
Please refer to for details on these approaches. Please note that alternative approaches may be equally valid for this task.
Summary
Objective
A terminology server should support services that are required for patient- and population-oriented data retrieval and analytics tasks. The objective of expression query services is to enable subsumption testing between expressions and enable selective retrieval of postcoordinated expressions satisfying stated criteria.
Description
Subsumption TestingWhen expressions are used, it is necessary to determine whether the meaning of a particular expression is a subtype of a specified concept or more generally is subsumed by a particular expression constraint. The terminology services required are similar to those described for testing concepts in sections 4.5 Get and Test Concept Subtypes and Supertypes.
Selective Retrieval
As for precoordinated concepts, expressions may be queried based on the inferred properties derived from the classification process. Expression constraints may be formulated and executed against the expression repository and the associated substrate to return both precoordinated concepts and expressions that match the specified constraint, see .
Summary
Transform the updated expressions (update the classifiable form expressions)
Classify the expression repository against the new substrate, and where relevant, generate new versions of the necessary normal form
Get concepts and expressions that conform to an expression constraint
- repId: a unique reference to the expression repository
- ecl: an expression constraint complying to the ​
Success: Return a set of conceptIds and CTU expressions that conform to the expression constraintOptionally additional information such as the fully specified name or preferred term of each concept included in the expansion plus generated terms for included expressions​Failure: Return error message if expression constraint contains syntax errors​Return error message if any concept identifiers in the expression constraint are not present in the specified edition
Create expression repository
Creates a new repository
- substrate : the base edition for this repository
- languages (0-*): pairs of language refsetIds + language codes used to generate descriptions (optional)
Success: True, with identifier of the generated repository
Failure: False, with appropriate error message
Get details about an expression repository
Gets details of a repository
- substrate: the base edition for this repository
- repId: a unique reference to the expression repository
Success: Return details of the selected expression repository and dependencies
Failure: Return error message
Update expression repository
Creates a new version of a specific repository
- substrate : the new base edition for this repository
- repId : identifier of the repository to be updated
- languages (0-*): pairs of language refsetIds + language codes used to generate descriptions (optional)
Success: True
Failure: False, with appropriate error message
Add expression
Adds a new postcoordinated expression to the expression repository
- substrate: the base edition for this repository
- repId: a unique reference to the expression repository - CTU: Close to user form expression
Success: Return data associated with the expression
Expression identifier, if generated
CTU expression
CF expression, if generated
NNF relationships, if generated
Failure: "Expression not added" plus an indication of the reason (e.g. transformation issue, classification issue, term generation issue)
Validate and transform expression
Check that the CTU is syntactically valid and conforms to the concept model rules, or allowed rules for postcoordination. Transforms the close-to-user form expression to a classifiable form
- id: a unique reference to the expression repository - expId: CTU expression or expression id
Success: True
Failure: False, with validation error indication
Generate NNF
Classifies the expression (CF) and generates the necessary normal form of the expression
- repId: a unique reference to the expression repository - CF: Classifiable form
Success: As a minimum, returns the necessary normal form of the expression
Failure: Display an appropriate error message
Search for expression
Find expression by term
- repId: a unique reference to the expression repository
- Search string
- Search technique option (if required)
- Search filtering or sorting options (if supported)
Success: A collection of matching terms each of which is linked to an expression within the expression repository.
Display term (generated)
Expression identifier
Failure: Return an appropriate error message
Get term for expression
Gets an autogenerated term for the expression using the technique supported by the terminology server
- substrate: the base edition for this repository- id: a unique reference to the expression repository
- expression: a unique reference to the expression
- technique: if multiple techniques for generating terms exist, the technique to apply may be indicated
Success: Return the generated display term(s)​Failure: Display an appropriate error message
Query expression
Subsumption - check if there is a subsumption relationship between two expressions
- repId: a unique reference to the expression repository
- source: CTU expression, expression id, or concept id
- target: CTU expression, expression id, or concept id
Success: Return data to inform which of the following outcomes are true:
Source is a subtype of target
Target is a subtype of source
No subsumption relationship between source and target
Failure: Display an appropriate error message
Query expression
Implementing an expression repository using the standard format specified by SNOMED International is comparable to the implementation of a SNOMED CT extension. As for SNOMED CT extensions, the content contained in the expression repository depends on a specific versioned Edition of SNOMED CT, and it requires ongoing maintenance to align with new versions of SNOMED CT.
The difference between a common SNOMED CT Extension and an Expression Repository Extension can be summarized as follows:
Difference in the representation of clinical meanings
Clinical meanings expressed in a common extension are represented as SNOMED CT concept components and require creation and management by SNOMED CT authors
Clinical meanings expressed in an expression repository extension are represented as SNOMED CT expression components
Difference in the content included
A common SNOMED CT Extension may contain various components and derivatives (see )
An expression repository extension contains only the components and derivatives required to represent postcoordinated expressions Consequently, the following components and derivatives may be contained to meet the requirements outlined in :
Expression components to uniquely identify the expressions
The image below illustrates the logical model of an expression repository extension.
Implementing an expression repository involves the creation of expression components, where the expression identifier uses the partition id of '16'. For more information about SNOMED CT identifiers, please refer to the
This identifier enables the unique identification of an expression and is used to establish a link between all required forms of the expression.
The expression identifier is:
Used as the id for the expression component
Referenced in the as the value of the referencedComponentId
Referenced in the as the value of the referencedComponentId
The moduleId attribute of the expression component refers to a concept that represents and names the module in which the expressions are maintained. This concept is a subtype of , and the terms associated with this concept should clearly indicate that this module is an expression repository, e.g. .
The CTU is stored in a separate reference set which is of the type .
Expressions in the close-to-user form will get an effectiveTime as soon as they are saved, this will match that of the current dependent code system version.
The CF is stored in a separate reference set which is of the type .
Members in the classifiable form reference set are given an effectiveTime. This will happen before the code system is upgraded to a new dependent version. Once these components are versioned they will keep the effectiveTime until the values of their fields are changed, via the transformation or classification processes. At this point changed components will have their effectiveTime cleared and will be versioned again when the code system is next versioned.
Following the classification of the CF expression, the NNF of the expression is represented as relationships. In the same way as SNOMED CT concepts, expression components include subtype and attribute relationships to represent the properties of the expression.
Components of expressions in the classifiable and necessary normal forms will have an effectiveTime set when the expression code system is versioned. This will happen before the code system is upgraded to a new dependent version. Once these components are versioned they will keep the effectiveTime until the values of their fields are changed, via the transformation or classification processes. At this point changed components will have their effectiveTime cleared and will be versioned again when the code system is next versioned.
A reference set to hold the CF expressions
Expression relationships to represent the NNF of the expressions
A component annotation reference set to hold the display terms associated with the expression
Release process
Extensions are released
Expressions are not released
Used as the source of the expression relationships to represent the necessary properties of the expression
Terminology servers at Level 1 will accept any expressions represented in valid classifiable form, as in Level 0. Additionally, some expressions that are not already in classifiable form will also be accepted. These will mainly be syntactically compliant expressions that are not MRCM compliant, but which the server can unambiguously transform to derived expressions that are MRCM compliant, using predefined automated transforms.
A loose attribute is any attribute within a CTU expression that is not in an attribute group AND the MRCM specifies:
that it should be grouped, or
that it is in the wrong domain
Level 1 transformations of CTU expressions may apply to expressions meeting the following criteria.
Transformations can only apply where there is no definition status
There must be only one focus concept
Level 1 transformations can only apply to loose attributes (as defined above)
When the expression contains a mixture of loose attributes and attribute groups, the attribute groups are effectively treated as for Level 1, so no transformation of these are attempted
Expression syntax, concepts being active and MRCM attribute-range validation should be applied before the transformation step. Implementations should fail fast if these are not met and not attempt transformation. This simplifies the preconditions for specific transformations.
The process of applying the transformations is iterative. This includes: collecting the set of remaining loose attributes, then applying the next transformation, and repeating until each transformation has been applied once. When each specific transformation is applied it should be greedy and transform all the loose attributes that meet the conditions of that transformation.
The list of transformations must be applied in a specific order; to ensure that the same classifiable expression is reached every time by all implementations.
The allowed patterns can be summarized as follows:
Refining Existing Attribute
Adding a Self-grouped Attribute
Adding Severity to Clinical Findings
Lateralizing Clinical Findings
The following sections elaborate on the preconditions and behaviour of each pattern.
In this case, the terminology server will accept attributes-value pairs with the following characteristics:
The attribute is already present in the NNF of the focus concept
The attribute value stated in the expression is a subtype of the attribute value of the focus concept
Important Notes
If no groups are stated in the CTU expression (i.e. attributes are declared as loose attributes), the terminology server will accept attribute-value pairs correctly belonging to role groups of the focus concept as follows:
The terminology server will accept attribute-value pairs that refine one or more of the attribute-value pairs of the focus concept, i.e.
The attribute type should be the same as, or a subtype of, an attribute that already exists in the NNF of the focus concept, for which
This transformation will be applied to all loose attributes that meet the following conditions:
The attribute applies to the MRCM domain of the focus concept (see table below)
Only one instance of the attribute is stated in the CTU expression
Although the MRCM allows multiple instances, this transformation condition aims to avoid misinterpretation of the intended meaning
Either:
Please refer to the Editorial Guide for instructions on the use and the implied meaning of these attributes:
Clinical Finding Defining Attributes
Procedure Defining Attributes
As part of the expression transformation process, the terminology server will place the attributes in groups on their own, as shown in the examples below.
At level 1, the terminology server will accept CTU expressions matching the following pattern:
This means that CTU expressions that includes the severity attribute will be accepted if the following criteria are met:
The focus concept is a subtype of |Clinical finding| (but not a subtype of )
The attribute value must be a subtype of
When applied as a loose attribute, only one instance of the attribute may be stated in the CTU expression
The severity attribute is not already present in the definition of the focus concept
As part of the transformation process, the terminology server will place the attribute in a group on its own, similar to the self-grouped attributes.
The terminology server will accept CTU expressions matching the following pattern:
The transformation of expressions following this pattern will include the following steps:
Copy the defining properties and role groups of the focus concept (as present in the NNF) to the classifiable form expression
Replace the value of the |Finding site| attribute with a nested expression:
From:
To:
Important Notes
When applying the concept as the value for the attribute, the transformation should be done in accordance with the modeling applied to the content in the International Edition of SNOMED CT.
This means that the transformation steps described above should be applied twice; one for each lateral half, as illustrated in the example below.
The terminology server will accept CTU expressions matching the following pattern:
The transformation of expressions following this pattern will include the following steps:
Copy the defining properties and role groups of the focus concept (as present in the NNF) to the classifiable form expression
Replace the value of the |Procedure site| attribute (or any of its subtypes / @siteAttribute) with a nested expression:
From:
To:
When applying the concept as the value for the attribute, the transformation should be done in accordance with the modeling applied to the content in the International Edition of SNOMED CT.
This means that the transformation steps described above should be applied twice; one for each lateral half, as illustrated in the example below.
At level 1, the terminology server will accept CTU expressions matching the following pattern:
This pattern allows attributes applicable to the domain to be used to add contextual information to clinical finding concepts.
The generated classifiable form must be based on the following expression with as the focus concept and the following default attributes and values unless otherwise specified by the CTU. The value of the Associated finding attribute will be replaced by the focus concept of the CF expression.
At level 1, the terminology server will accept CTU expressions matching the following pattern:
This pattern allows attributes applicable to the domain to be used to add contextual information to procedures.
The generated classifiable form must be based on the following expression with as the focus concept and the following default attributes and values, unless otherwise specified by the CTU. The value of the Associated procedure attribute will be replaced by the focus concept of the CF expression.
Adding Context to Clinical Findings
Adding Context to Procedures
The attribute value may be the same as, or a subtype of, the existing attribute value
The terminology server will reject attribute-values, if this is a supertype of the attribute value used in the definition of the focus concept
If groups are stated in the CTU expression
The terminology server will accept groups that refine an existing role group of the concept, i.e. the group stated in the CTU should represent a subtype of the role group of the focus concept
: =
Accept
=== : { = } { = } { = } { = }
: =
Accept
=== : { = , = }
: =
Reject
N/A
: =
Accept
=== : { = , = , = } { = , = , = } { = , = , = }
The attribute type is not already used in the necessary normal form of the focus concept
For example, if the focus concept already has a |Due to| attribute in the NNF then an expression including |Due to| would not be accepted
The attribute type is already used in the necessary normal form of the focus concept and the value is equal to or a subtype of the existing value
I.e. it represents a refinement
due to
clinical course
temporally related to
associated with
: =
Accept
=== : { = , = }, { = }
: =
Accept
=== :{ = ( : = )}
: =
Reject
N/A
: =
Reject
N/A
: =
Reject
=== : { = ( : = )} { = ( : = )}
: =
Accept
=== : { = ( : = ), = } { = ( : = ), = }
: =
Reject
N/A
: =
Reject
N/A
: =
Accept
=== : { = , = ( : = ), = } { = , = ( : = )}
: =
Reject
N/A
: = , =
Accept
=== : { = , = , = , = }
Accept
=== 29477005 |Repair of fracture with sequestrectomy| : { 260686004 |Method| = 129284003 |Surgical action| , 363704007 |Procedure site| = 272673000 |Bone structure| , 405816004 |Procedure morphology| = 72704001 |Fracture| } { 260686004 |Method| = 257903006 |Repair - action| , 405813007 |Procedure site - Direct| = 26107004 |Structure of musculoskeletal system| } { 260686004 |Method| = 129304002 |Excision - action| , 405813007 |Procedure site - Direct| = 272673000 |Bone structure| , 363700003 |Direct morphology| = 4857006 |Sequestrum| } { 260686004 |Method| = 129284003 |Surgical action| , 363704007 |Procedure site| = 41111004 |Bone structure of shaft of femur| , 405816004 |Procedure morphology| = 72704001 |Fracture| } { 260686004 |Method| = 257903006 |Repair - action| , 405813007 |Procedure site - Direct| = 41111004 |Bone structure of shaft of femur| } { 260686004 |Method| = 129304002 |Excision - action| , 405813007 |Procedure site - Direct| = 41111004 |Bone structure of shaft of femur| , 363700003 |Direct morphology| = 4857006 |Sequestrum| }
Accept
before
priority
during
has focus
after
Accept
Reject
[[+ (< 404684003 |Clinical finding| MINUS << 162465004 |Symptom severity| ) @finding]]:
246112005 |Severity| = [[+ (<< 272141005 |Severities (qualifier value)| ) @severity]]Accept
Reject
N/A
Reject
[[+ (< 404684003 |Clinical finding| ) @finding]]:
272741003 |Laterality| = [[+ (< 182353008 |Side| ) @side]]@finding.363698007 |Finding site| = @bodySite363698007 |Finding site| = (@bodySite: |Laterality| = [[+ @side]] )301354004 |Pain of ear| : 272741003 |Laterality| = 51440002 |Right and left|=== 301354004 |Pain of ear| :
{ 363698007 |Finding site| = ( 117590005 |Ear structure| : |Laterality| = 7771000 |Left| )},
{ 363698007 |Finding site| = ( 117590005 |Ear structure| : |Laterality| = 24028007 |Right| )Reject
N/A
Reject
[[+ (< 71388002 |Procedure| ) @procedure]]:
272741003 |Laterality| = [[+ (< 182353008 |Side| ) @side]]@siteAttribute = @bodySite@siteAttribute = (@bodySite: |Laterality| = [[+ @side]] )| 52734007 |Total replacement of hip| : 272741003 |Laterality| = 51440002 |Right and left| |=== 52734007 |Total replacement of hip| :
{ 363698007 |Finding site| = ( 117590005 |Ear structure| : |Laterality| = 7771000 |Left| )},
{ 363698007 |Finding site| = ( 117590005 |Ear structure| : |Laterality| = 24028007 |Right| )}Accept
=== 14600001000004107 |Closure of wound of ankle with flap| : { 260686004 |Method| = 129357001 |Closure - action| , 405813007 |Procedure site - Direct| = ( 344001 |Ankle region structure| : 272741003 |Laterality| = 7771000 |Left| ), 363700003 |Direct morphology| = 13924000 |Wound| , 424361007 |Using substance| = 256683004 |Flap| }
Accept
[[<< 404684003 |Clinical finding| @finding]]:
[[0..1]] 408729009 |Finding context| = [[+id(<< 410514004 |Finding context value| )@context]],
[[0..1]] 408731000 |Temporal context| = [[+id(<< 410510008 |Temporal context value| )@time]],
[[0..1]] 408732007 |Subject relationship context| = [[+id(<< 125676002 |Person| )@person]]=== 413350009 |Finding with explicit context| :
{ 246090004 |Associated finding| = 404684003 |Clinical finding| ,
408729009 |Finding context| = 410515003 |Known present| ,
408732007 |Subject relationship context| = 410604004 |Subject of record| ,
408731000 |Temporal context| = 410512000 |Current or specified time| }Reject
N/A
Accept
[[<< 71388002 |Procedure| @procedure]]:
[[0..1]] 408730004 |Procedure context| = [[+id(<< 288532009 |Context values for actions| ))@context]],
[[0..1]] 408731000 |Temporal context| = [[+id(<< 410510008 |Temporal context value| )@time]],
[[0..1]] 408732007 |Subject relationship context| = [[+id(<< 125676002 |Person| )@person]]=== 129125009 |Procedure with explicit context| :
{ 363589002 |Associated procedure| = 71388002 |Procedure| ,
408730004 |Procedure context| = 385658003 |Done| ,
408732007 |Subject relationship context| = 410604004 |Subject of record|
408731000 |Temporal context| = 410512000 |Current or specified time| }Accept
=== 129125009 |Procedure with explicit context| : { 363589002 |Associated procedure| = 42125001 |Excisional biopsy of breast mass| , 408730004 |Procedure context| = 410525008 |Needed| , 408732007 |Subject relationship context| = 410604004 |Subject of record| 408731000 |Temporal context| = 410512000 |Current or specified time| }
Reject
Important Notes: Please be aware that caution should be taken when adding |severity| to a focus concept, because severities are difficult to generalize and may be subject to individual interpretation, as stated in the Editorial Guide.
Important Notes
The terminology server will only accept expressions complying to this pattern where the focus concept has the following characteristics:
The focus concept
includes only one role group with a @siteAttribute 363704007 |Procedure site| attribute (or any subtype of 363704007 |Procedure site|) OR
includes two or more role groups with a 363704007 |Procedure site| attribute (<< 363704007 |Procedure site|) WHERE
the @bodySite value is the same for all procedure site attributes
includes no attributes with values that are lateralized anatomical structures
The value of the procedure site attribute is a member of the
i.e. the associated body structure is lateralizable, and
the associated body structure does not already state a laterality
Important Notes
The terminology server will only accept expressions complying to this pattern if the focus concept of the CTU expression has the following characteristics:
The focus concept
is the concept 404684003 |Clinical finding| or a subtype hereof
For each expression, only one instance of each attribute is accepted
The value of the attribute must be within the allowed range of the attribute as specified by the MRCM
Important Notes
The terminology server will only accept expressions complying to this pattern if the focus concept of the CTU expression has the following characteristics:
The focus concept
is the concept 71388002 |Procedure| or a subtype hereof
For each expression, only one instance of each attribute is accepted
The value of the attribute must be within the allowed range of the attribute as specified by the MRCM
=== : { = , = } { = , = , = } { = , = , = }
N/A
N/A
N/A
=== : { = , = ( : = ), = , = } { = , = ( : = ), = }
=== : { = , = , = , = }
N/A