Restore requirement to look at M_APPLIED_PATH when retrieving modifier info from the Ontology Cell

In release 1.7.03, a change was made in the Ontology cell to no longer require the M_APPLIED_PATH when retrieving the modifier information and the associated concept. This change has introduced problems in the i2b2 Web Client, Workbench, and overall response time.

When the Ontology cell receives a getModifierInfo message it ignores the M_APPLIED_PATH; it only looks at the C_FULLNAME to determine what modifier(s) to return. Depending on how your modifiers are defined in the metadata table you could have hundreds of modifiers returned instead of the one that matches the M_APPLIED_PATH and C_FULLNAME. This can result in a large response message being returned to the i2b2 Web Client or Workbench. This in turn causes performance issues in regards to slow response times when a modifier is added to a panel in the Query Tool or edits are made to the Modifier Value constraints window.

In addition to performance issues, this change also introduced problems in both the Web Client and the Workbench.

1. In the Web Client, the wrong value constraints can be displayed in the Modifier Value Constraint window. This is because the client does not know which modifier in the list returned in the xml message is the correct one, so it takes the data from the first one.
2. In the Workbench, the value constraints that display in the Modifier Value Constraint window appear to be duplicated several times. Since the workbench doesn’t know which one is the right modifier, it is displaying the data for numerous modifiers.
3. Web Client queries cannot be re-run in the Workbench if the query has a modifier with a value constraint. The query will fail because the value constraint will be duplicated for each modifier.


The change made in 1.7.03 (CORE-143) was done to support SHRINE networks that did not have the modifiers in their SHRINE ontology mapped to the modifiers in the local site ontologies. The query would fail because the M_APPLIED_PATH that was sent from the SHRINE would be the one from the SHRINE ontology and therefore would not exist in any of the local ontologies. The solution at the time was to have the Ontology cell ignore the M_APPLIED_PATH.


NEW SOLUTION:
In release 1.7.07 the Ontology cell will once again look at the M_APPLIED_PATH when determining the appropriate modifier information to return. The fix has been modified slightly; logic will now be added that will fix the i2b2 and support SHRINE Networks that do not have their modifiers mapped.

The following logic will be added to the fix:

-- If the Ontology Cell finds the M_APPLIED_PATH in the metadata table then only one modifier will be returned.

-- If the Ontology Cell does not find the M_APPLIED_PATH then it will ignore it and return all modifiers with the appropriate C_FULLNAME.