Page tree

Date & Time

20:00 UTC Wednesday 6th July 2016

GoToMeeting Details

Click here to see GoToMeeting joining information


  • To progress the SNOMED CT Template syntax

Agenda and Meeting Notes


Welcome, introductions and apologies

Linda Bird 
Agenda reviewLinda BirdReview agenda for today's meeting
Recap of last meetingLinda Bird

STEP 1 - Convert SNOMED CT Expression Template into FHIR Structure Definition (for use as Target of Mapping)


  • SNOMED CT Expression Template

[[ [1..1] @findingWithExplicitContext ]]:

#[1..2] @RGa { 246090004 |Associated finding| = ([[ [0..1] @associatedFinding ]]:

#[0..1] @RGb { 246112005 |Severity| = [[ [0..1] @severity]],

363698007 |Finding site| = [[ [0..1] @findingSite]] })

408732007 |Subject relationship context| = 410604004 |Subject of record|,

408731000 |Temporal context| = [[ [1..1] @temporalContext ]],

408729009 |Finding context| = [[ [1..1] @findingContext ]] }

  • FHIR Structure Definition

SCT_ConditionTemplate: SNOMEDCTExpressionTemplate

findingWithExplicitContext [1]: Coding

group [1..2]: RelationshipGroupElement

associatedFinding [1]: Coding

group [0..1]: RelationshipGroupElement

severity [0..1]: Coding

findingSite [0..1]: Coding

subjectRelationship [1]: Coding410604004 |Subject of record|

temporalContext [1]: Coding

findingContext [1]: Coding

STEP 2 - Define Mapping Rules from Source Structure (FHIR Resource) to Target Structure (SNOMED CT Expression Template)


Condition: Resource

code [1]: CodeableConcept (coding [1..*] - system, version, code, display, userSelected [0..1] - text [0..1])

category [0..1]: CodeableConcept (values: complaint | symptom | finding | diagnosis)

clinicalStatus [0..1]: code (values: active | relapse | remission | resolved)

verificationStatus [1]: code (values: provisional | differential | confirmed | refuted | entered-in-error | unknown)

severity [0..1]: CodeableConcept

bodySite [0..1]: CodeableConcept


SCT_ConditionTemplate: SNOMEDCTExpressionTemplate

findingWithExplicitContext [1]: CodeableConcept

group [1..2]: RelationshipGroupElement

associatedFinding [1]: CodeableConcept

group [0..1]: RelationshipGroupElement

severity [0..1]: CodeableConcept

findingSite [0..1]: CodeableConcept

subjectRelationship [1]: CodeableConcept = 410604004 |Subject of record|

temporalContext [1]: CodeableConcept

findingContext [1]: CodeableConcept


rule_1: for  source.code as code where verificationStatus != "entered-in-error" then {

rule_1afor code where code in memberOf("") make target.findingWithExplicitContext = 413350009 |Finding with explicit context|, as groupA then {

rule_1aafor code make groupA.associatedFinding = code

rule_1abfor code where severity in memberOf("") OR findingSite in memberOf(" make as groupB then {

rule_1abafor source.severity as sev where severity in memberOf("") make groupB.severity = sev

rule_1abbfor source.bodySite as bs where findingSite in memberOf(" make groupB.findingSite = bs }

rule_1acfor code make groupA.subjectRelationship = 410604004 |Subject of record|

rule_1adfor code make groupA.temporalContext = 410512000 |Current or specified time|

rule_1aefor source.clinicalStatus as cs, source.verificationStatus as vs  make groupA.findingContext as fc then {

rule_1aea: for vs make fc.code = translate ('status-to-findingContext-map', cs, vs)

 rule_1aeb: for vs make fc.system = ""

 rule_1aec: for vs make fc.display = ", 900000000000509007)

} }

  rule_1b: for code where code in memberOf(" ") make target.findingWithExplicitContext = code then {


} }

Outstanding question - Q1Linda BirdDo we need to support naming of SNOMED CT Relationship Groups within the SNOMED CT Expression Template syntax? For example: [[ .... ]]: @RelationshipGroupName { .......}
  • Note: This requirement comes from the need for a stable name for each relationshipgroup, in the FHIR Structure Definition used to represent the SNOMED Expression Template that is the target of a mapping (examples above).
  • A possible alternative would be to not include relationship group names in the template, and instead rely on a reproducible approach to automatically generating these names (e.g. RG1, RG1.1, RG1.2, RG2, RG2.1). However, because these names are used in the mapping code, we would need to ensure that they are absolutely stable - so given this, is this approach appropriate?
Outstanding question - Q2Linda BirdWhat syntax should we use to define cardinality constraints?
  1. On a focus concept, an attribute or an attribute value - e.g. in the relevant slot [[ [1..*] < 123456 @slotName ]]
  2. On a relationship group - e.g. 123456 |concept|: #[1..*] { .......}
    • Note: The syntax must clearly indicate that the cardinality on a relationship group does not appear in the concrete expression that is generated when the expression template is populated. This is needed to distinguish an Expression Template (with relationship group cardinalities) from an Expression Constraint Template (for which the relationship group cardinalities do appear in the populated version of the template). In this example syntax, the "#" is being used to say "The following constraint needs to be removed when the template is populated."
Outstanding question - Q3Linda Bird

What is the expected behaviour when a cardinality constraint in an Expression Template is not met?

Outstanding question - Q4

Linda Bird

Are there any other template requirements that we haven't yet considered for other use cases (e.g. for concept authoring)

Confirm next meeting date/timeLinda BirdNext meeting to be held at 20:00 UTC on Wednesday 20th July

Meeting Files

No files shared here yet.

  • No labels


  1. Regarding the descendantOf (404684003 |Clinical finding|)  style functions.  These can currently be done using the fluentpath function memberOf and an implicit SNOMED CT ValueSet:

    For example, memberOf("") would be the equivalent of << 404684003 |Clinical finding| – if it was important to exclude the "self" bit then you'd have to add in an extra clause to exclude that case.

    For the preferredTerm (en-us, coding.code) function, I've raised a question about invoking $lookup from fluentpath, but I feel the need to point out that the SNOMED CT notion of preferredTerm is relative to a language reference set, not an ISO 639-x language code.

  2. Thanks for the information about using the memberOf function for subsumption testing. Where can I find a specification of what functions and URIs patterns (after the "?") are allowed?

    With respect to the preferredTerm .... yes I am very aware that preferred terms are defined in each language refset. I just didn't have time to look up the language refset id at the time. I have corrected this now, with a 'made-up' syntax, until an official one becomes available.

    Thanks again!