Observable and Investigation Model Project

Page tree

Earlier in the projects history it was decided not to use role groups for the Observables model, mainly because at the time, the model was proposed to include nested definitions more specific than what role grouping admits. Also, the nesting patterns using role groups for procedures and findings (i.e. having more than one "part" of the procedure or more than one "condition" for the finding) does not apply to observables. There will only ever be one kind of quality and observation procedure referred to by one observable.

Below is an example of the relationship table for an observable created using SnoOwl from UNMC:

ideffectiveTimeactivemoduleIdsourceIddestinationIdrelationshipGrouptypeIdcharacteristicTypeIdmodifierId
389446341000004000 19000000000002070007996353510000040001173620050370132008900000000000225000900000000000451000
154043481000004000 1900000000000207000799635351000004000641950000704320005900000000000011000900000000000451000
113689121000004000 19000000000002070007996353510000040004434120090116680003900000000000011000900000000000451000
953865841000004000 19000000000002070007996353510000040003676510030704319004900000000000011000900000000000451000
978593911000004000 19000000000002070007996353510000040004416520080704327008900000000000011000900000000000451000
326682591000004000 190000000000020700079963535100000400077604299100000400009216841000004100900000000000011000900000000000451000
557253841000004000 19000000000002070007996353510000040001185360000704318007900000000000011000900000000000451000
326573721000004000 19000000000002070007996353510000040001230290070370134009900000000000011000900000000000451000
232992231000004000 19000000000002070007996353510000040002580660000246501002900000000000011000900000000000451000

As can be seen, all relationship groups (role groups) are 0. Most attributes use to define observables are exclusive to the observables model, with the exception of 246093002 | Component (attribute) |. The same SnoOwl tool outputs observables concepts as below:

The RF2-to-OWL script provided with the international release of SNOMED CT role groups everything that isn't explicitly marked as "never grouped" by hard coding the list of attributes not to be "automagically" put into role groups. All other attributes are currently put inside a role group, even if relationshipGroup equals 0 in the RF2 file.  Currently these "never grouped" attributes are:

$nevergrouped{"123005000"} = "T"; # part-of is never grouped
$nevergrouped{"272741003"} = "T"; # laterality is never grouped
$nevergrouped{"127489000"} = "T"; # has-active-ingredient is never grouped
$nevergrouped{"411116001"} = "T"; # has-dose-form is never grouped

There are three possible solutions:

  1. Always role group all observables into one group. + easy to achieve, - no straightforward corresponding semantics (as for findings and procedures)
  2. Make observables use two role groups, one for target of observation (quality, disposition, function) and one for the observation procedure, + almost as easy, - interim solution, "semi-straightforward" semantics only
  3. Create a new COMPONENT-like attribute exclusive to the observables model and add all observables attributes to the "never grouped" list. + easy to achieve (see David Sperzel's comment), - lack of re-use between models (procedures and observables)
  4. Remove role groups from evaluation procedures (which should be observables anyway?), - more invasive solution (~9000 concepts, 15 with explicit, but still only 1, role group)
  5. Add rules to OWL generation software (or similar) which distinguishes between observables and procedures, - more complex software --> harder to implement
  6. [added 2016-10-12 ] Remove implicit role grouping, as described in comment below.

 

  • No labels

11 Comments

  1. Jim Case

    Given the native role-grouping of the RF2-to-OWL script, it would be of interest to know the rationale behind that particular implementation strategy. Role groups provide a much needed construct for semantics and it inconsistent use in the terminology as a whole has caused substantial inference inconsistencies.

  2. Kai Kewley

    Could anyone explain if a non is-a relationship in group 0 within RF2 should always become an attribute in OWL which is not nested?
    Following on from Jim's comment perhaps an ungrouped RF2 relationship should become an unnested OWL attribute but that conversion would not be reliable because of inconsistent use of grouping?
    I would like to understand this if someone has the time to explain it to me or point me to some resources. Many thanks.

  3. Daniel Karlsson

    Hi Kai,

    according to the TIG (4.3.5.2.2 Relationship Grouping) and the perl script, apart from the (currently) four attributes (127489000 | Has active ingredient (attribute) |, 123005000 | Part of (attribute) |, 272741003 | Laterality (attribute) |, and 411116001 | Has dose form (attribute) |), relationships in group 0 are always grouped.

    From the TIG:

    "When transforming Relationships to OWL or KRSS, all rows that have a RelationshipType that are allowed to be grouped, even if a particular row is ungrouped (i.e. even if the row has a RelationshipGroup value meaning ‘ungrouped’), must be nested under an existential restriction that represents the (potential) grouping. This existential restriction is labeled with the OWL object property called ‘Role group (attribute)’"

    Note that this is currently the thing which is closest to a specification of SNOMED CT formal semantics!

    /Daniel

  4. Daniel Karlsson

    Also, I sincerely believe that removing this idea of implicit relationship grouping and making relationship grouping mandatory for Clinical findings, Procedures, and Specimen and disallowed for all other hierarchies would be a step towards clarity, easy-of-use, and predictability. It would also make implementations, including SNOMED CT-2-OWL transformations, less error prone as this whole issue would disappear.

    This change could be made algorithmically (e.g. by incrementing the relationshipGroup field by one for all non-IsA relationships for the specified hierarchies). Then, relationshipGroup 0 means "not grouped" and not "maybe grouped sometimes depending on hierarchy".

    /Daniel

  5. Farzaneh Ashrafi

    QA resulting form the observable implementation call on October 3, 15.00 UTC:

    Hi Daniel,
    On the call today this question came up: is there a strong technical reason or other reason against role grouping in the Observables model (related to option 1: "Always role group all observables into one group. + easy to achieve, - no straightforward corresponding semantics (as for findings and procedures)" presented here).
    The group needs the answer to this question before they can make a decision on how to proceed.
    Thanks,
    Suzanne
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hi,

    There is no strong (or weak) technical reason not to relationship group observables. However, there are strong semantic reasons:

    1. an observable can never be about two things. It's something that can have one and only one value. Even for panels, it would not make sense to use relationship groups, as that would make it impossible to distinguish between one observable and a panel containing one observable. Every observable would be a panel of depth 1. Panels of panels (which do exist out there!) could not be implemented this way.

    2. for procedures, findings and (perhaps not as clearly) specimen there is an (reasonably clear) interpretation of the role group: for findings it's a condition, for procedures it's a procedural step or part, for specimen, it's used for multi-part specimen (e.g. 309287004 | Hysterectomy and bilateral salpingo-oophorectomy sample (specimen) |). For observables there is no such interpretation. 

    3. there has been one proposal to use relationship groups for observables to mimic the nested model (of yesterday...) by having exactly two groups. However, this would introduce a completely new way of using relationship groups which deviates from their use for procedures, findings, and specimen.

    /Daniel

  6. Jim Case

    Daniel,

    There was a proposal on the call the other day to effectively require "role-grouping" for all non-IS A relationships that would be an attempt to clarify the perceived ambiguity around role group 0.  What this would mean, as I understand it is that all non-IS A attributes would be assigned to role group "1" by default and more specific grouping needed for other hierarchies such as findings and procedures would begin numbering their groups from "2" onward.  At first, I was opposed to doing this as it would add more complexity to the already complex notion of when to group, but if it could be implemented in the tooling, then that would not be as much of a problem (although I see scenarios that give me heartburn).  The real question is whether this just kicks the can down the road and does not really solve the issue at hand?  Thoughts?

    Jim

  7. Harold Solbrig

    Jim,

    This would be a good way to call attention to the issue, assuming that there is still a role group of "0" for the properties that are never grouped.  Was that your intent? At the moment, the fact that we've got secret role groups and that some, but not all, of the relationships are assumed to belong to them is not widely known.   Making this information obvious and explicit would be a good first step towards not kicking the can down the road.  Until we can make the issue obvious and visible, it is going to be difficult to get any traction towards a real solution.

     

    Harold

    1. Daniel Karlsson

      Yes, 0 = no group!

  8. Daniel Karlsson

    Hi Jim,

    first I'm happy to do (almost) whatever is needed to facilitate implementation of the Observables model, so if this is the decision then let's go with that.

    However, I think there are more issues with relationship grouping and that this is just a symptom of some underlying problems ("tip of an iceberg" kind of metaphor). I made a comment on the MAG discussion page about relationship grouping in general. This probably needs more thinking, but I believe that relationship groups just like any other part of the definition should be there for the way it represents meaning of the concept, not as a workaround for other problems. It seems that relationship groups have been applied inconsistently, at least if judged by the meaning asserted e.g. by ECE.

    Another solution which would be just as easy to apply and would keep the semantics of the relationship group would be to increase the relationshipGroup with 1 for findings, procedures, and specimen in the stated definitions. At the same time, in the MRCM, make relationship grouping mandatory for said hierarchies. The idea is to remove the need for implicit relationship grouping in tools and transformations. Then, a review of existing relationship groups would be also be in order.

    /Daniel

  9. Scott Campbell

    The use of role group 0 is not well known in the SNOMED CT community, nor is the impact of role grouping on descendant concepts and classification well understood.  With this said, is the suggestion to move all concepts currently bound to a role group 0 to a different role group 1?  If so, are all these concepts to be in the same role group 1, and therefore, shown to be explicitly part a a single role group?  Or is this simply a change from the nominal role group number?

    If efforts to group concepts in a single role group that were previously in independent role group 0's, why not progress to assigning unique numbers to role groups?  It may be something that would benefit authoring quality/consistency, as well as, nesting. 

    1. Daniel Karlsson

      The idea was to increase all groups, 0→1, 1→2, etc. Relationship group 0 would mean no group, ever.