Syntax check, constraints and dominance

[annrat]

Hi Ngene experts
I'm a novice Ngene user so I'm attempting to design my first DCE. I have 2 healthcare alternatives (treatment v no treatment), 6 attributes, 5 with 3 levels and 1 with 2 levels. The no-treatment option has only 3 attributes (recur, mild tox, cost is always $0) as you would expect that if you're not receiving treatment there are no fatal or permanent side-effects and no cost. Regarding logical/plausible choice tasks I've added one constraint that I think restricts pts having 4 weekly treatment to 2 levels of cost, $750 or $1500. Could you confirm this is correct?

As this is a patient and clinician DCE I'm trying to limit the scenarios and have attempted to create 2 blocks of 9 choice sets so each participant will see 9 scenarios, is this correct? Another alternative was to create 12 rows (scenarios).
I'm unsure if my syntax is correct as Ngene has been working for over 3 hrs now and has completed nearly 300,000 evaluations, does this sound correct?

I have a few issues with dominance and can see how to address these with unlabelled DCE how do I do this with a labelled DCE?

For example, I don't want a scenario where the chance of cancer returning is lowest, the chance of treatment side effects is lowest, the frequency of treatment is lowest, and the cost is the lowest. How do you suggest I manage this?

Thanks Ann

design
;alts=treat, notreat
;rows=18
;block=2
;eff=(mnl, d)
;cond:
if(treat.reg=4, treat.cost=[750,1500])
;model:
U(treat) = b1[0.5]*recur[36,42,50] +
b2[-0.005]*mild[1,12,37] +
b3[-0.1]*fatal[0,1,3] +
b4[-0.05]*perm[1,10,14] +
b5[-0.001]*reg[3,4] +
b6[-0.03]*cost[750,1500,6000] /
U(notreat) = b1 *recur2[50,56,62] +
b2 *mild2[11,17,33] +
b6 *cost2[0]
$

[Michiel Bliemer]

1. The constraint is correct.
2. If there are no fatal side-effects, then you need to include this attribute and set it to zero, just like you do with cost.
3. There needs to be a constant in one of the alternatives in a labelled experiment.
4. Strict dominance is an issue for unlabelled experiments, in labelled experiments this technically cannot occur because of the constant and the differences in how attributes are perceived. But if you notice choice tasks that have an issue, you can simply remove them manually. In that case, just generate a larger number of choice tasks and remove the ones you believe problematic afterwards.
5. Yes 18 rows with 2 blocks means a respondent faces 9 choice tasks.
6. Ngene will never stop evaluating designs, there are billions of possible designs and it takes a long time for Ngene to evaluate all, so it simply continues until the user presses the stop button. For a simple design like this, you can probably stop after a few minutes.

Michiel

[Michiel Bliemer]

I notice also that your prior for cost is inappropriate, it should be much closer to zero, it now completely dominates choice. Please use priors coming from a pilot study, otherwise set them to zero or be extremely conservative.

[annrat]

Hi Michiel
Thank you so much for your comprehensive response.
Regarding the 3 attributes that are 'not applicable' for the 'no treatment' option i.e. permanent and fatal toxicity, and how frequently the treatment is given these are slightly different to the 'cost' attribute for no treatment which is zero cost, as pts are having no treatment.
Therefore given this background do I still add each of these attributes and set it to zero as below? Just to confirm the mild toxicity levels for no treatment are included as they have been reported in clinical trials as the placebo arms.

Regarding the constant has this issue been addressed in the revised syntax below?

The issue with priors is following completion of patient qualitative research prolonging life was most important, with patients being averse to (in order most to least averse) fatal, permanent toxicities, cost, mild toxicity, then costs. So the priors are best guesses what would you suggest the range should be?

design
;alts=treat, notreat
;rows=18
;block=2
;eff=(mnl, d)
;cond:
if(treat.reg=4, treat.cost=[750,1500])
;model:
U(treat) = b0 + b1[0.5]*recur[36,42,50] +
b2[-0.005]*mild[1,12,37] +
b3[-0.1]*fatal[0,1,3] +
b4[-0.05]*perm[1,10,14] +
b5[-0.001]*reg[3,4] +
b6[-0.03]*cost[750,1500,6000] /
U(notreat) = b1 *recur2[50,56,62] +
b2 *mild2[11,17,33] +
b3 *fatal2[0] +
b4 *perm2[0] +
b5 *reg2[0] +
b6 *cost2[0]
$

[Michiel Bliemer]

The constant is fine. If you do not use all attributes in notreat then the utilities simply end up in this constant, so that is fine, you can leave out the attributes that are N/A in notreat.

Your priors are an issue, they are not appropriate. I cannot tell you what they should be, but the current priors are far too large. For example, b1=0.5 and multiply9ing with 50 means a contribution to utility of 25, which is HUGE. A typical contribution of an attribute to utility is generally no more than 1. The same for cost, 0.03 * 6000 = 180, which makes no sense.

If you do not know how to set priors properly using expert judgement or a pilot study, then they need to be set to 0 or very small positive/negative values. Simply 'guessing' priors is not a good idea and typically leads to very bad/inefficient design. Using zero priors is always safe.

Bliemer, M.C.J., and A.T. Collins (2016) On determining priors for the generation of efficient stated choice experimental designs. Journal of Choice Modelling, Vol. 21, pp. 10-14.

Michiel

[annrat]

Thanks Michiel for all your advice.
I've updated the syntax following some further discussion around framing, conditional statements, attributes and levels as follows:

Design
;alts=drug,nodrug
;rows=12
;eff=(mnl,s)
;block=5
;cond:
if(drug.rega=4, drug.costa=[750,1500]),
if(drug.recura=50, nodrug.recurb=[56,62])

;model:
U(drug)= reg[-0.3]*rega[3,4]+recur[-0.05]*recura[36,42,50]+mild[-0.03]*milda[1,12,37]+perm[-0.1]*perma[1,10,14]+fatal[-0.5]*fatala[0,1,3]+cost[-0.0002]*costa[750,1500,6000] /
U(nodrug)=ascb+reg*regb[0]+recur*recurb[50,56,62]+mild*mildb[0]+perm*permb[0]+fatal*fatalb[0]+cost*costb[0]
$

With regards to the ASC, what are the pros and cons of having a prior value?

[Michiel Bliemer]

If the label has an important influence on the choice, i.e. if the probability for selecting drug is very different from selecting no drug all else being equal, then using a zero prior for the ASC will lead to incorrect choice probabilities, which will result in incorrect efficient measure computations, and a D-efficient design may actually not be very efficient since it was optimised under ''wrong' choice probabilities. The more the ASC deviates from zero, the more loss in efficiency.

Michiel

[annrat]

Thanks Michiel for your expert advice