CDR Tickets

Related Glossary Term

Looking at the September 1 comments on [WCMSGK-27], the key to this is that GK needs to know the Term in each of the languages it appears in. (e.g. "Scan" vs. "exploración".) From the GK perspective, what's needed is multiple instances of the RelatedGlossaryTermRef element, each containing the term in a different language, and a (new) UseWith attribute specifying the language. A new instance is required for each of the target term's audiences, specifying both language and audience.

UseWith is a required attribute.

The assumed business rules are

• A GlossaryTerm will never have a related GlossaryTerm which doesn't appear in the same dictionary.

• CancerGov will only display related glossary terms which are in the same language as the current display.

GlossaryTermRef in a Summary

((Related ticket from WCMS??))

When a Summary contains a GlossaryTermRef GK needs to know the language, audience, and dictionary it's intended to use.

GlossaryTerm definitions can belong to one of three dictionaries: CancerGov, Genetics, and "Unspecified".

The intent is to reduce GK and CancerGov's level of guesswork in resolving the links.

Default is audience = patient and dictionary = CancerGov (aka "Dictionary of Glossary Terms")

~LearnB the WCMS ticket for the second comment is: https://tracker.nci.nih.gov/browse/WCMSGK-2

Business rules are (partially?) outlined in comments on [WCMSGK-2].

Rules will be updated and placed in a central location. (Collaborate / RTM)

~ShahAj and ~volker to consolidate the current rules for reference.

Our current plan is to send this information to CancerGov via additional attributes on the GlossaryRef and RelatedGlossaryTerm elements.

Does this change need to be stripped form the data sent to dissemination partners?

Additional concerns:
What happens when a referenced definition is removed? GK will need to fallback to a default definition.

Filter changes may need to be made in conjunction with WCMSGK-40, which is going to be done as a hotfix. ~volker and ~learnb to coordinate.

~learnb - I will send an email to confirm these rules

GateKeeper code changes are in svn at https://ncisvn.nci.nih.gov/svn/oce_wcmteam/GateKeeper/branches/epione

~volker The DTD entry for RelatedGlossaryTermRef should be:

<!ELEMENT RelatedGlossaryTermRef              (#PCDATA)>
<!ATTLIST RelatedGlossaryTermRef href  CDATA  #REQUIRED>
<!ATTLIST RelatedGlossaryTermRef  UseWith (en | es) #REQUIRED>
<!ATTLIST RelatedGlossaryTermRef  audience (Patient | HealthProfessional) #REQUIRED>

I'll leave it to you to make the official change. ;-)

<!ATTLIST RelatedGlossaryTermRef  audience (Patient | HealthProfessional) #REQUIRED>

For consistency in our DTD I'll go with

<!ATTLIST RelatedGlossaryTermRef  audience (Patients | Health_professionals) #REQUIRED>

From our meeting with Margaret and William on 4/13- it is safe to assume that we would only have related terms within the same dictionary, as well as the same language. Thanks!

To finish up the filter changes I had one last question for Blair. The question was the following:
We know that a related glossary term should always be pulled from the same dictionary and the same language and one would assume if a glossary is specified as a related term for a HP dictionary that a HP definition exists for that related term. Should the GK code drop a link if the term doesn't exist for a specific dictionary or should the CDR code drop the link.
Answer: The CDR should drop the link if the dictionary does not exist.

The filter has been updated accordingly and I believe we are ready for testing.

The following filters have been updated (located in the trunk sandbox):

• CDR616047: Denormalization Filter: GlossaryTermName

• CDR616048: Vendor Filter: GlossaryTermName

This ticket had been migrated to PROD as part of Epione.

• R14686: Denormalization Filter: GlossaryTermName (CDR616047)

• R14686: Vendor Filter: GlossaryTermName (CDR616048)

Closing ticket.