"cc" conditioning issue with Rwanda algo

[GregMart1n]

Describe the bug

When using Rwanda algo, if for example "Fever" is checked, it will trigger FEVER WITHOUT SOURCE. Then the questions are well displayed until "Other source of fever" is reached. It seems to not pass because the rest of the diagram is never dislayed.

Context

https://medalcreator.unisante.ch/algorithms/6/versions/72/diagnoses/6115/diagram

Screenshots

Works with TZ where "Identifiable source of fever" is displayed.

Additional information

There is a suspicion that other CC have the same wrong behavior. Not sure if it's a reader issue.

[GregMart1n]

Msg from the field : Hi Greg - I have now got it to work by modifying the PDS to this - it's a work-around but seems ok - still would be good to know why it works in Tanzania without it though. Fever can never be "No" as it has to be "Yes" to enter the algorithm, but it allows all patients who enter the algo to pass through the PDS

[GregMart1n]

@ManuBarchich This diagram works well on the TZ side : https://medalcreator.unisante.ch/algorithms/1/versions/77/diagnoses/6574/diagram

URL : http://195.15.219.241/ ID : 1335

[GregMart1n]

Salut Manu,

Have you been able to find anything on this issue ?

[ManuBarchich]

Hello, je suis toujours en attente d'un moyen de tester le comportement sur TZ en comparaison à RW, suite à notre discussion du 31.01

[GregMart1n]

TZ algo test URL : http://195.15.219.241:8080/ Device ID : 1808

RW algo test URL : http://195.15.219.241:8080/ Device ID : 1809

[quentingirard]

Après investigation, le PS Other source of fever reste avec une answer null du fait que les premiers réponses soit des complaint categories. De plus, le diagnostic Other source of fever n'a pas encore été ajouté dans la liste des diagnostics à calculer.

Deux solutions possibles, faire une nouvelle implémentation afin de recalculer un PS lorsqu'un nœud pointe sur lui ⚠️perte de performance ⚠️. Ou, ne pas utiliser les complaint categories dans ce cas de figure

[GregMart1n]

Hello, L'explication ne semble pas convaincre l'utilisateur. il me dis qu'il n'y a aucune différence entre l'algo de TZ et RW. Tu m'avait dit que quelque chose était différent dans le cheminement en les 2. Pourrais-tu me redonner l'info? Merci

[quentingirard]

Suite au message du 27 février

Après investigation, le PS Other source of fever reste avec une answer null du fait que les premiers réponses soit des complaint categories. De plus, le diagnostic Other source of fever n'a pas encore été ajouté dans la liste des diagnostics à calculer.

Deux solutions possibles, faire une nouvelle implémentation afin de recalculer un PS lorsqu'un nœud pointe sur lui ⚠️perte de performance ⚠️. Ou, ne pas utiliser les complaint categories dans ce cas de figure

Contexte

Le diagramme Other source of fever où la question Identifiable source of fever? est affiché.

Explication

Pour TZ, le PS Other source of fever est déclenchée par le PS ENT source of fever qui lui-même est déclenché par la question Default true qui utilise BD5 comme formule.

Cette question Default true est calculée dès que le clinicien saisi la date de naissance. Par effet de cascade, va jusqu'au PS Other source of fever et calcule ça valeur (false).

Dans le cas de RW, le PS Other source of fever est déclenchée par le PS ENT source of fever qui lui-même est déclenché par la question <3m/3-35m/>=36m qui utilise une formule ToMonth.

Ce PS n'est pas calculé lorsque le clinicien saisie la date de naissance. De ce fait, le PS Other source of fever garde comme réponse (null)