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.