Stream: terminology
Topic: normalForm property
Michael Lawley (May 17 2017 at 00:34):
SNOMED defines three normal forms: Long NF, Short NF, and Distribution NF. Which one should this property use?
BTW @Peter Jordan your server is not getting the grouping in normalForm propertys right. For example it returns
384821006|Mental state, behaviour and/or psychosocial function finding|:
{
363714003|Interprets|=247583006|Decision making|,
363714003|Interprets|=311465003|Cognitive functions|,
363714003|Interprets|=3850002|Psychological function|
}
rather than each relationship being grouped separately (which is what role group = 0 means)
384821006|Mental state, behaviour and/or psychosocial function finding|:
{ 363714003|Interprets|=247583006|Decision making| },
{ 363714003|Interprets|=311465003|Cognitive functions| },
{ 363714003|Interprets|=3850002|Psychological function| }
Peter Jordan (May 17 2017 at 00:54):
@Michael Lawley I'm sure that I read somewhere that role group = 0 denotes no grouping - but will check that and make the necessary correction in my next update. I've interpreted normalForm as Long NF and normalFormTerse as Short NF.
Michael Lawley (May 17 2017 at 00:59):
I thought it was clear thet normalFormTerse is just normalForm but without the display text. ie codes and syntax but no terms
In SNOMED, there are some atrributes that are "never grouped" (eg laterality), but all others are always grouped. role group = 0 means that those attributes are still grouped, but it is implicit. If you were going to use this, then the correct syntax would be:
384821006|Mental state, behaviour and/or psychosocial function finding|:
363714003|Interprets|=247583006|Decision making|,
363714003|Interprets|=311465003|Cognitive functions|,
363714003|Interprets|=3850002|Psychological function|
i.e., no braces at all. But this form is "Close to User" form, which is not one of the Normal(ised) Forms.
Peter Jordan (May 17 2017 at 01:11):
Thanks, in the short term it will be easier to implement that syntax with the curly braces. I have interpreted normalFormTerse as being normalForm without the descriptions/terms.
Michael Lawley (May 17 2017 at 01:18):
@Grahame Grieve 's server is a little strange - it only returns a single code if the concept is primitive, otherwise it looks like it returns the Long NF
Note the difference between your result for 139461000119109 and Grahame's ; the Associated finding is expanded in his, but not yours
Grahame Grieve (May 17 2017 at 05:48):
what exactly is strange?
Peter Jordan (May 17 2017 at 08:33):
@Michael Lawley My Server returns the following Normal Form Expression for 139461000119109|History of osteoporotic fracture|
243796009|Situation with explicit context|:{408732007|Subject relationship context|=410604004|Subject of record|,408731000|Temporal context|=410513005|Past|,408729009|Finding context|=410515003|Known present|,246090004|Associated finding|=443165006|Pathological fracture due to osteoporosis|}
How am I failing to expand the Associated finding property? OTOH, Grahame's is returning an Associated Finding of 64572001|Disease|
Peter Jordan (May 17 2017 at 09:09):
@Michael Lawley the normalForm expression that my server returns for SCT concept 384821006 is actually...
384821006|Mental state, behaviour and/or psychosocial function finding|:363714003|Interprets|=3850002|Psychological function|
Are you looking at the correct server and noting the edition, because I can only see a single attribute for that concept in the 20170131 version of the International Edition of SCT? Still take the point on role group = 0, but need another example to test the correct syntax.
Michael Lawley (May 17 2017 at 09:16):
Have a look at what Graham's server returns - the normal form of 443165006|Pathological fracture due to osteoporosis| should be provided as the value of 246090004|Associated finding| :
243796009|Context-dependent categories| :
{
408732007|Subject relationship context|=410604004|Subject of record|,
408731000|Temporal context|=410513005|Past|,
408729009|Finding context|=410515003|Known present|,
246090004|Associated finding|=64572001|Disease|:{116676008|Associated morphology|=22640007|Pathologic fracture|,363698007|Finding site|=272673000|Bone structure|},{42752001|Due to|=64859006|Osteoporosis|}
}
Although this is slightly wrong syntactically as there should be brackets around an attribute value that is not just a single code.
Michael Lawley (May 17 2017 at 09:16):
@Grahame Grieve it's strange because the single primitive code is not a "normal form" of the code.
To be consistent with your use of Long Normal Form for fully-defined concepts you would need to include the relationships of the primtive concept as well.
Peter Jordan (May 17 2017 at 09:33):
@Michael Lawley are you effectively saying that, where appropriate (e.g. associated findings), attribute values have to be expanded into expressions?
Michael Lawley (May 17 2017 at 09:35):
That's the definition of Long Normal Form, yes. The Long Normal Form should only comprose primitive concepts
Peter Jordan (Jun 01 2017 at 04:54):
@Michael Lawley I'm struggling to understand the Long Normal Form expression that your server is returning for 126716006 | Neoplasm of right lower lobe of lung (disorder) | ...
126713003 |Neoplasm of lung|:
{116676008 |Associated morphology| = 108369006 |Neoplasm|,
363698007 |Finding site| = 266005 |Structure of lower lobe of right lung|}
The focus concept 126713003 |Neoplasm of lung| and one of the defining attributes 266005 |Structure of lower lobe of right lung| aren't primitives (unless this an edition/version issue).
Michael Lawley (Jun 01 2017 at 05:37):
That would be because we're not returning Long Normal Form, but rather (extended) Distribution Normal Form
The spec doesn't (yet) say which normal form should be provided
Grahame Grieve (Jun 01 2017 at 05:37):
that sort of thing is in scope for a snomed implementation guide which we are supposed to work on with Snomed International
Peter Jordan (Jun 01 2017 at 05:40):
Couldn't we just add an additional property for Distribution Normal Form, e.g. NormalFormDistribution? Then we could state explicitly that the existing NormalForm property is Long Normal Form and NormalFormTerse is Short Normal Form?
Grahame Grieve (Jun 01 2017 at 05:47):
we could. I'm not sure that the word 'just' is rightin that sentence
Peter Jordan (Jun 01 2017 at 05:51):
I could have used 'simply' instead. :)
Grahame Grieve (Jun 01 2017 at 05:57):
that would have been automatic yellow card, given that we are dealing with SNOMED CT
Michael Lawley (Jun 01 2017 at 06:58):
normalFormTerse is already defined as "normalForm without the display text"; it's not a different norma form.
What is needed is a decision on whether normalForm is LNF or SNF (I'm not really convinved that DNF is what's wanted/useful, it's just easiest)
Peter Jordan (Jun 06 2017 at 06:29):
@Michael Lawley I've taken myself back to (Compositional) Grammar School and re-factored my code that generates LNF expressions. When time permits, perhaps you could look at the results and feedback any errors. One discovery was that there is no comma between ungrouped and grouped attributes (TIG page 107). Unfortunately, the definitions of the concepts that provide most of the 'non-trivial' examples in the SCT documentation have changed significantly since publication, so aren't useful from a testing perspective.
Michael Lawley (Jun 14 2017 at 04:27):
I believe that the comma is optional - see the refinement rule in the spec here https://confluence.ihtsdotools.org/display/DOCSCG/5.1+Normative+Specification -- a comma before any attributeGroup (except the first when there's no attributeSet) are optional
Michael Lawley (Nov 14 2018 at 06:06):
@Peter Jordan @Rob Hausam I've created tracker GF#19647] as per (I hope) today's SNOMED on FHIR discussion to either remove the normalForm properties or at minimum note their semantic limitation.
Last updated: Apr 12 2022 at 19:14 UTC
