CDR Tickets

Let me know when the requirements have been finalized.

The original requirements as attached are final now. Please use it for the implementation.

I have made slight modifications to the requirements. 

It is okay to have two separate reports, one each for Glossary and Media. Please let me know if you want to create 2 separate tickets. It will also be helpful to be able to search definition documents and not just the glossary documents. 

Glossary and Media Keyword search report_updated.docx

Please let me know if you want to create 2 separate tickets.

Yes, please.

Glossary Keyword search report.docx

I have modified the title to reflect that the focus will be on the Glossary keyword search report. I have also updated the requirements and removed the requirements for the media doc from it.

Ability to search the definitions of glossary term name and concept documents

I don't think term name documents have definitions. You list the term name string elements under this heading (alongside the definition elements). Don't we already have reports which find glossary terms by name (for example, the advanced glossary term search page)?

Glossary Keyword search report_Corrections.docx

I have made the correction in the attached updated requirements document. I believe that are reports for searching glossary terms but I am not sure that there is one that will accomplish the same purpose as this request.

Well, as long as you have presented your business case for this report to Margaret and gotten it approved. In this case, you'll probably want to eliminate the sentence "We want to be able to search for specific words within a definition document." from the requirements document.

Which of the fields (language, audience, etc.) are required? For which can the user specify more than one value?

Please be specific as to which fields are used for selection, and which fields are used for determining where the keywords to be displayed should be drawn from. When you say "... specify the audience of the document" you imply that we are to find glossary terms which have a definition for the designated audience, but are to look in all definitions for the keywords. Is this right? Please say exactly what is meant by "specify the language."

Are the definitions to be searched as they are stored in the concept documents? Or are the placeholders to be resolved and the generated version of the definition searched for each of the term's names?

No mention is made of highlighting/rich text, so I assume that's not a requirement, right?

Perhaps it would be better if you were to explain at today's status meeting the underlying problem you would like to solve with this new report (including any helpful background information), it would be easier to determine what the specific requirements should be. Thanks.

Sure. 

I am attaching a revised document providing information on search criteria. I also updated the requirements the requirements removing some of the desired features. Glossary Keyword search report_Corrections_Selection_Criteria.docx

~mbeckwit since this is one of the larger tickets we've undertaken in a while, could I get your approval before starting in on the design and implementation?

To summarize, this will involve

• parsing each glossary term (possibly thousands of them)

• generating separate versions of each definition in each concept with placeholders resolved for each of the concept's term name documents

• normalizing the generated definitions and each of the term names (including alternate names) for searching for each of the phrases specified by the requestor of the report

• custom code to create rich-text markup inside table cells (both HTML and Excel)

• benchmarking the report to determining whether exceeds the time limits for the web server and needs to be converted to run as a batch job (and if so, perform that conversion)

Thanks!

~mbeckwit and ~duganal: do we have the green light for this request?

We agreed in the 2021-04-08 status meeting that we will proceed with implementing this report. We decided we will use the same approach for highlighting the target terms using added characters instead of rich text. We also agreed that we will do the searching of the exported GlossaryTerm documents instead of the original GlossaryTermName and GlossaryTermConcept CDR documents, in order to be working with definitions which have already had placeholders resolved. This will mean that documents which have not yet been publishing will not be included in the report (this satisfies another of the requirements, that blocked documents be excluded from the report). It also means that only term names which have been published (exported) will be searched.

Same question about specifying wildcards in search terms as with the media keywords report.

~oseipokuw Can you clarify an ambiguity in the requirements, which talk about using Audience to "indicate whether to search Patient or HP definitions Or Patient or HP Terms." As far as I can tell, definitions are assigned a specific audience, but the terms themselves are not. A term document can have

1. Patient definitions

2. HP definitions

3. Patient and HP definitions

4. No definitions

... but the terms themselves are not HP or Patient terms.

So let's take a specific case. A glossary document has a name which contains "toenail cancer" and a single definition, with the audience set to "Health professional." The user gives "toenail cancer" as the phrase to be searched, and "Patient" as the audience. Should the report ignore this document or include it?

Implemented on CDR DEV.

Please ignore the requirements document references to the audience of the term (instead of the definition). By the way, we've done some testing on DEV and the report appears to work as expected. Thanks!

Verified on DEV. Thanks!

When a search term that is in both dictionaries (Patient and HP) is supplied, the definitions for both dictionaries are displayed even when the user selects one dictionary  (in this case Health Professional).  Please see attached screenshots. 

The requirements say

Also, providing the CDR IDs of both the GTNs and GTCs, Term Names and Definitions, highlighting the retrieved terms and showing surrounding text if applicable

and

Elements to Search:

1. Term Name string

2. Definition Text

So the definitions are given as both elements to be displayed as well as elements to be searched. The audience is used for filtering used to determine which glossary terms are to be included on the report, not for determining what will be displayed for those terms. I assume that if we found the target term in the term name string but not in the definitions for that term's concept you wouldn't want us to ignore the instructions to display the definitions, right?

 I assume that if we found the target term in the term name string but not in the definitions for that term's concept you wouldn't want us to ignore the instructions to display the definitions, right?

That is right. Displaying the definitions is helpful and they should not be ignored. Is it the same case for the issue reported above?

Right. The way I read the requirements, the audience is used for deciding which documents are selected for the report, not which definitions should be displayed for those selected documents.

For the same search term in the screenshot above "autosomal dominant inheritance"  When the audience is changed from "Health Professional" to "Patient", Only one definition is displayed. Shouldn't two definitions be displayed just as when I selected "Health Professional" ?

Tell you what. Modify the requirements to say explicitly which parameters control document selection (and how) and which parameters control data display (and how), and I'll make the report match those requirements.

The report works very well when there is only one definition block for a term. It also seems to display exactly as expected from other terms or definitions that are not directly linked to the search term. Where there seems to be some inconsistencies is when the search term has multiple definition blocks in the search term's own linked GTC document and you select "Health Professional" for the Audience option. 

This is our preference for the display:

1.  Display the definition only if the search term is in the definition. - Allele as example --I believe this is happening as expected when you select "Patient" for the Audience. However, when you select "Health Professional", the "Patient" definition is also displayed even though the term "Allele" is not in that definition.

2. When a search term  is in both dictionaries,  for example - "autosomal dominant inheritance" - The definition to display should match the Audience selected by the user. So, if a term is in both dictionaries, and a user selects "Patient" as Audience, please display only the "Patient" definition, and the other way around.

3. If a search term is in both dictionaries ,  for example - "autosomal dominant inheritance" - and a user selects "Any" for the Audience option, please display all the definitions from the GTC that is directly linked to it'

Does the shift in requirements (don't show a definition at all if it doesn't contain one of the search terms) also apply to the name column (don't show the name at all if it doesn't contain one of the search terms)?

While waiting for the answer to my last question, I have

1. applied the new rule for leaving out display of definitions which don't contain any of the search terms; and

2. corrected "Health Professional" (which is what the requirements have) in the picklist to "Health professional" (which is what's in the documents); that should eliminate some of the anomalies you ran into.

These changes are only on DEV right now.

Does the shift in requirements (don't show a definition at all if it doesn't contain one of the search terms) also apply to the name column (don't show the name at all if it doesn't contain one of the search terms)?

Please show the name. It does not apply to the name column.

OK. When I get the word that the changes I have installed on DEV produce the results you now want, I'll install those changes on QA.

Verified on DEV. Please install on QA. Thanks!

Modifications installed on QA.

Verified on QA. Thanks!

Verified on PROD. Thanks!