Examples of representation of concrete domains in AMT

The following document is provided by Dion McMurtrie for discussion.

Below is a concept definition taken from AMT showing a simple example. The example shows 2 tablets in a pack, which is the datatype property.

Declaration(Class(:SCT_63262011000036107))

AnnotationAssertion(rdfs:label :SCT_63262011000036107 "paracetamol 500 mg tablet, 2 tablets (medicinal product pack)")

EquivalentClasses(:SCT_63262011000036107 ObjectIntersectionOf(:SCT_30513011000036104 ObjectSomeValuesFrom(:RoleGroup ObjectSomeValuesFrom(:SCT_30348011000036104 ObjectIntersectionOf( :SCT_23628011000036109 ObjectSomeValuesFrom(:RoleGroup ObjectIntersectionOf(ObjectSomeValuesFrom(:SCT_177631000036102 :SCT_63011000036109 ) DataHasValue(:SCT_700000131000036101 "2"^^xsd:decimal ))) )))

))

Diagrammed this looks like

From the RF2 content this looks like

Table 1 Concepts file

id	effectiveTime	active	moduleId	definitionStatusId
63262011000036107	20090630	1	900062011000036108	900000000000073002

Table 2 Descriptions file

id	effectiveTime	active	moduleId	conceptId	languageCode	typeId	term	caseSignificanceId
386203011000036117	20090630	1	900062011000036108	63262011000036107	en	900000000000003001	paracetamol 500 mg tablet, 2 tablets (medicinal product pack)	900000000000017005
386204011000036115	20090630	1	900062011000036108	63262011000036107	en	900000000000013009	paracetamol 500 mg tablet, 2	900000000000017005

Table 3 Stated relationships file

id	effectiveTime	active	moduleId	sourceId	destinationId	relationshipGroup	typeId	characteristicTypeId	modifierId
1974711000168128	20140630	1	900062011000036108	63262011000036107	30513011000036104	0	116680003	900000000000010007	900000000000451002
1974721000168124	20140630	1	900062011000036108	63262011000036107	23628011000036109	0	30348011000036104	900000000000010007	900000000000451002

Table 4 Stated concrete domain reference set file

id	effectiveTime	active	moduleId	refsetId	referencedComponentId	unitId	operatorId	value
a2a03443-3b46-4e32-9a87-7b39ab799ae6	20140630	1	900062011000036108	700000131000036101	1974721000168124	63011000036109	700000051000036108	2

Note that the yellow cells show that the reference set row references the relationship id – this indicates that the concrete domain value being added is nested under this relationship.

Note also that the green field indicates the reference set id, which is used as the datatype property type. The blue column “unitId” is the unit for the scalar value provided, this was put into the single reference set row rather than a separate statement as it is easier for consumers to deal with.

There are plenty of examples of this in AMT – this technique is used for strengths, unitary medication size, pack size and sub pack sizes.

Matt has written a page on it here https://snomed.atlassian.net/wiki/display/IAP/Use+of+Concrete+Domains+in+AMT

The Concrete Domain Specification details how all this works, it can be found at https://snomed.atlassian.net/wiki/display/IAP/Options+paper+for+representing+Numbers?preview=%2F33498037%2F33498119%2FRF2+Specification+Change+Request+-+Addition+of+Concrete+Domains+v0.6.1.doc

The bit we’re interested in is how this affects the logic. That is covered in section 3.1.5 which I’ve copied below for easy reference.

The bottom line is that the intention was

If the reference set references a concept, the datatype property and unit are role grouped together for the concept with no additional nesting – AMT doesn’t use this
If the reference set references a relationship, then “target” of the relationship will be the conjunction of the relationship target concept and a role group of the datatype property and unit.

This achieves the additional level of nesting required, particularly important for strengths of multi ingredient drugs. I’ve included a diagram of one of these below, it is a more complex example than I detailed above, but the principle and implementation in RF2 is the same, just more rows.