The SNOMED CT Template Syntax is designed to convert any formal SNOMED CT language into a SNOMED CT Template Language. A SNOMED CT template contains slots, which provide a placeholder in the expression, constraint or query, whose specific value can be completed at a subsequent time using a value recorded within an information model, entered into a data entry form, or sourced by some other means.
Status
The SNOMED CT template syntax version 1.0 has been published at http://snomed.org/sts. This specification includes the SNOMED CT expression template language v1.0 - http://snomed.org/etl.
Implementations
SNOMED International is aware of the following implementations of the SNOMED CT Expression Template Language:
- SNOMED International
- SNOMED Template Service: https://github.com/IHTSDO/snomed-template-service
- Generated parser and examples: https://github.com/IHTSDO/SNOMEDCT-Languages/tree/master/SnomedCTExpressionTemplateLanguage
- B2i Healthcare - https://github.com/b2ihealthcare/snomed-etl
- Nictiz Netherlands - https://github.com/mertenssander/postco
Future Versions
Additional requirements are being collected for consideration in future versions of the SNOMED CT Template Syntax. In the following sections, we describe some of these proposed requirements under consideration.
Support for an Expression Constraint Template Language
Adding guidance, syntax, and a model of input data to support the use of slots in the Expression Constraint Language.
Default Values
The ability to state the default value for a slot using the template syntax. For example .... [ slotName ws] [ "[ =" defaultValue "]" ]
Equal and Not Equal Values
The ability to say that the value of two slots must be equal, the value of two slots must be different, or the value of one slot must be subsumed by the value of another slot.
Conditional occurrence
The ability to say that an attribute is allowed to occur at most once in a role group. However, if the attribute is present, then it must be present in every repeat of that role group. - e.g. |Occurrence| attribute
See ticket #22789
3 Comments
Daniel Karlsson
I've made an example implementation of (a | the) template syntax:
https://github.com/danka74/SNOMEDCTTemplatePreprocessor
and a slide deck to go with that:
https://docs.google.com/presentation/d/1orjJhs7H42xOGQocOL5B34WM81IpllZ-Z1b8-Q0dbLI/edit?usp=sharing
Daniel Karlsson
I believe there would be a solution without scope markers where the slot would have to indicate the extent of the scope, i.e. current refinement, current role group, current concept definition (up to the level of any nesting), or total concept definition (up to the top level), e.g. [[ R 1..1 @variable ]] for a refinement scope. The down side would be that it is less flexible, e.g. you can't express dependency between two out of three refinements but that expressiveness might not be needed. The other "issue" (or not) is that the whole expression needs to be parsed to figure out the actual scope instead of just scanned for scope markers.
Linda Bird
Thanks for your thoughts on this Daniel.
You will need to help me understand why a slot needs to define the extent of its scope.
In particular, why can't all this logic be pushed into the mapping/transformation code?
And do other tree-based data structures that are used as the target of a map/transformation need to define the extent of the scope of each data element?
The main difference that I see between mapping to a traditional tree-based data structure versus mapping to a SNOMED CT expression template, is that in a data model the 'grouper nodes' (ie the nodes that group together a set of data elements) tend to have distinct names (or paths), which can be referred to in the mapping logic .... while in a SNOMED CT expression template, the relationship groups don't have an obvious way of being referred to (from the mapping logic). I am assuming that the mapping/transformation code will need to have some way of referring to each slot, as well as each relationship group - so that it can specify when refinements and relationship groups (respectively) need to be repeated for multiple values in the data.
I suspect we need to start looking at an example of a template working together with the mapping logic, so that we can get a shared understanding of these requirements.
Kind regards,
Linda.