Page History

Welcome, introductions and apologies

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

CONDITION RESOURCE

• 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]: CodeableConceptCoding

RGa [1..2]: RelationshipGroupElement

associatedFinding [1]: CodeableConcept Coding

RGb [0..1]: RelationshipGroupElement

severity [0..1]: CodeableConcept Coding

findingSite [0..1]: CodeableConcept Coding

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

temporalContext [1]: CodeableConcept Coding

findingContext [1]: CodeableConcept Coding

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

SOURCE STRUCTURE

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

TARGET STRUCTURE

SCT_ConditionTemplate: SNOMEDCTExpressionTemplate

findingWithExplicitContext [1]: CodeableConcept

RGagroup [1..2]: RelationshipGroupElement

associatedFinding [1]: CodeableConcept

RGaagroup [0..1]: RelationshipGroupElement

severity [0..1]: CodeableConcept

findingSite [0..1]: CodeableConcept

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

temporalContext [1]: CodeableConcept

findingContext [1]: CodeableConcept

RULES

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

rule_1a: for code where code in descendantsOfdescendantOf (404684003 |Clinical finding|) make target.findingWithExplicitContext = 413350009 |Finding with explicit context|, target.RGa group as rga then {

rule_1aa: for code make rga.associatedFinding = code

rule_1ab: for code where severity in descendantsOfdescendantOf (272141005 | Severities|) OR findingSite in descendantsOfdescendantOf (123037004 |Body structure|) make rga.RGb as rgb then {

rule_1aba: for source.severity as sev where severity in descendantsOfdescendantOf (272141005 | Severities|) make rgb.severity = sev

rule_1abb: for source.bodySite as bs where findingSite in descendantsOfdescendantOf (123037004 |Body structure|) makergb.findingSite = bs }

rule_1ac: for code make rga.subjectRelationship = 410604004 |Subject of record|

rule_1ad: for code make rga.temporalContext = 410512000 |Current or specified time|

rule_1ae: for source.clinicalStatus as cs, source.verificationStatus as vs  make rga.findingContext as fc then {

rule_1aea: for vs make fc.coding as coding then {

rule_1aeaa: for vs make coding.code = translate ((clinicalStatus,verificationStatus), 'status-to-findingContext-map', code)

rule_1aeab: for vs make code.system = "http://snomed.info/"

rule_1aeac: for vs make code.display = preferredTerm (en-us, coding.code) }

} }

  rule_1b: for code where code in descendantsOf (413350009 |Finding with explicit context|) make target.findingWithExplicitContext = code then {

rule_1ba:

} }

• 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?

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."

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

Outstanding question - Q4

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