CTCAE and external resources

[varntzen (Vebjørn Arntzen)]

Hi all

Currently there is an archetype on review, Clinical Terminology Criteria for Adverse Events, Clinical Knowledge Manager. To be able to provide guidance to users to pick the correct grading for an adverse event, it is recommended to use an external resource in the user interface/implementation. The CTCAE is based on a hierarchy of codes from MedDRA, and CTCAE uses two of the levels within that hierarchy: The System Organ Class (SOC) and Term. Each severity grade of adverse event is linked to Term and Term is linked to SOC, and the grading criterias, ranging from 1 - 5, differs with each Term/SOC.

Challenging @NeillY, @bna, @erik.sundvall and other “techies” to discuss and share how to best implement this recommendation, using the CTCAE and other archetypes.

More concrete:
Any missing elements or archetypes to do so?
Are the available data types for element “Grade” sufficient and useful?
Other aspects to consider?

On your mark, Get set, Go !

Cheers, Vebjørn

[erik.sundvall]

As I mentioned in CR-936, sometimes you want to list the exact grading critera (see examples fpr grades 1-3 below) in certain simple templates where you don’t want to involve a terminology server. You may also want to, in EHR data, store exactly what the clinician saw data rather than a general non-symptom-specific Mild/Moderate/Severe wording.

CTCAE: MedDRA Code	CTCAE: MedDRA SOC	CTCAE Term	Grade 1	Grade 2	Grade 3	Grade 4	Grade 5	Definition
10016256	General disorders and administration site conditions	Fatigue	Fatigue relieved by rest	Fatigue not relieved by rest; limiting instrumental ADL	Fatigue not relieved by rest, limiting self care ADL	-	-	A disorder characterized by a state of generalized weakness with a pronounced inability to summon sufficient energy to accomplish daily activities.

I believe the currently suggested design covers the above requirements via the neat “workaround” choise bof data types for the “Grade” attribute, but maybe the documentation should include hints regarding how to query data (e.g. via AQL) in order to pick up the numerical value of the grade no matter if the person designing the template/application chose to use Ordinal or Scale.

[erik.sundvall]

Regarding implementing a useful demo, here is what somebody with time could do (by themselves or by asking ChatGPT ot Github Copilot for help) and then post a link to their open source code solution, in this discussion thread!

1. Get the CTCAE v5 excel file: https://ctep.cancer.gov/protocoldevelopment/electronic_applications/docs/CTCAE_v5.0.xlsx
2. Convert the rows from the above spreadsheet to a list of JSON objects that you then feed in to a Lunr index GitHub - olivernn/lunr.js: A bit like Solr, but much smaller and not as bright or similar search engine (client or serverside).
3. Make a user interface where a clinician can type words and get a weighted (priority-sorted) list of possible matching CTCAE terms/grades descriptions/definitions that match from the index. Show the results in a way that the makes it possible/easy to read all information from a CTCAE row (like the one in the post above)
4. Make it possible to click the grade descriptions in the search hit list, and by doing so adding as many CTCAE entries as you want to an openEHR composition based on the above mentioned CTCAE archetype (if possible including the selected symptom-specific grade description rather than the generic one, because that makes reading the CTCAE EHR entry more meaningful for other EHR readers that may not have access to a fancy widget with CTCAE-support).

The above could of course be done as a component in existing platforms (instead of as a freestanding app/page) for examlple a component for Medblocks or a widget for Better plattform and others according to the specification suggestions posted in Standardised API for custom GUI-widgets for openEHR-based form editors & renderers? - #8 by boris.marn or Cambio’s (not yet openly published) variant of adding LIT-based components to forms.

Step #3 above could of course be improved to use exisitng data as input rather than requiring the clinician to type search words, I might get back to detailing such a use case from patient reported symptoms omce we get a first version of this How to use the "Symptom/sign screening questionnaire" archetype - #13 by erik.sundvall running after workarounds due to Bug in export of ORDINAL texts defined in templates

Do note that @bna from DIPS has previously done parts of the above and demoed in a YouTube short CTCAE Prototype openEHR Form - YouTube but it uses browsing of the hierarchy rather than search and also uses generic rather than symptom specific grade descriptions. (see correction of crossed out text in post below)

[varntzen (Vebjørn Arntzen)]

@erik.sundvall

but it uses browsing of the hierarchy rather than search and also uses generic rather than symptom specific grade descriptions

Actually that’s not correct. The user can start writing in all the fields, and the list shortens for each character added. Also, both the available grading alternatives and their corresponding description is unique for each term. See Grade 2 on the two Cardiac disorder SOC’s in the snippet below.

[bna (Bjørn Næss)]

I made a simple script to extract the CTCAE terms from Excel and transform them into reusable terminology models. See the source here: GitHub - bjornna/ctcae-extractor-transformer: A simple script to extract CTCAE terms from Excel and transform into terminology modesl for openEHR applications

Based on the terminology models developers might create direct search on terms or a hierachical lookup user-interface. This will, of course, be adapted to end-users needs.

I have also suggested a change in the archetype (Clinical Knowledge Manager) in the review process.

My suggestion is to add a new element to carry the specific term definition as DV_CODED_TEXT. This is needed to carry the external terminology id of the term. In addition it makes it possible to have a single generic element for the grade based on a singel well-defined DV_ORDINAL.

I think this will make the archetype capable of both being simple to use and also able to carry all semantic attributes for a CTCAE score/grade.

[bna (Bjørn Næss)]

@bna

I have also suggested a change in the archetype (Clinical Knowledge Manager) in the review process.

@erik.sundvall - I would like your view on the redesign of the archetype. You proposed an interesting choice structure to solve the modelling challenge. What do you think of the new pattern?

BTW: we think the suggested pattern and sw solution for CTCAE also will work for TNM. The norwegian cancer project is looking for machine readable publications of the TNM classification.

[siljelb (Silje Ljosland Bakke)]

@bna

My suggestion is to add a new element to carry the specific term definition as DV_CODED_TEXT. This is needed to carry the external terminology id of the term. In addition it makes it possible to have a single generic element for the grade based on a singel well-defined DV_ORDINAL.

Hi Bjørn! Could you explain a bit further what information your proposed new DV_CODED_TEXT element would contain? Feel free to use examples from the output from your extraction script

[bna (Bjørn Næss)]

Here a few examples from the prototype.

Example 1: Cardiac disorders → Atrial fibrillation

CTCAETERM::1::Asymptomatic, intervention not indicated
CTCAETERM::2::Non-urgent medical intervention indicated
CTCAETERM::3::Symptomatic, urgent intervention indicated; device (e.g., pacemaker); ablation; new onset
CTCAETERM::4::Life-threatening consequences; embolus requiring urgent intervention
CTCAETERM::5::Death

Example 2: Psychiatric disorders → Depression

CTCAETERM::1::Mild depressive symptoms
CTCAETERM::2::Moderate depressive symptoms; limiting instrumental ADL
CTCAETERM::3::Severe depressive symptoms; limiting self care ADL; hospitalization not indicated
CTCAETERM::4::Life-threatening consequences, threats of harm to self or others; hospitalization indicated
CTCAETERM::5::Death

The coded list (terminology) is generated by the script based on the extracted categories from the Excel definition of CTCAE. I.e. here for depression: ctcae-extractor-transformer/categories.json at 1e763aee0c9a33c717e30deb2c80b7c985f269aa · bjornna/ctcae-extractor-transformer · GitHub

Attached is a screenshot from the prototype form:

And in the screenshot below you will se how the script also set the correct generic grade based on the ordinal defintion.

The archetype used in the prototype (and with an added “Grade classification” element is this: modelling-hackshow/openEHR-EHR-CLUSTER.ctcae.v0.adl at master · bjornna/modelling-hackshow · GitHub

Did this answer your question @siljelb ?

[siljelb (Silje Ljosland Bakke)]

Yes. But I don’t understand why we need both the grade classification and the grade value as separate elements. The grade classification contains the grade value, and can be populated from the knowledge base into the (in the archetype) empty DV_ORDINAL element “Grade”. As far as I can see from the excel file the terms are unique, and the exact code (10012378 in your example) can be put in the “Term” DV_CODED_TEXT element. Or have I missed something?