I am running clogit and get the message "Note: multiple outcomes within groups encountered." Is this something I should worry about or is this a normal message?"

It’s a “normal” message, but, in Stata 4.0 (or earlier), you may want to be concerned depending on your data.

Stata’s clogit has always done 1:n_i matching using the exact conditional likelihood. But in version 4.0 and earlier, it used an approximation to the likelihood for m_i:n_i matching when m_i > 1.

In Stata 5.0 and 6.0, clogit always uses the exact conditional likelihood. So, it doesn’t matter what type of data you have; it always gives appropriate estimates.

First, let me explain what I mean by 1:n_i matching, etc. Let i index the groups (called strata by clogit in versions 4.0 and earlier). 1:n_i matching means that in the i-th group, there is 1 subject (i.e., observation) with a dependent variable y = 1 and there are n_i subjects with y = 0.

For 1:n_i matching, version 4.0 clogit and versions 5.0 and 6.0 clogit x give EXACTLY the same answers.

“Multiple positive outcomes within groups encountered” means there is at least one group j with m_j:n_j matching, where m_j > 1; i.e., in the j-th group, there are 2 or more subjects with y = 1. This general model is often called the conditional fixed-effects logit model.

In version 4.0 and earlier, the approximation used for m_j:n_j matching was only good when m_j << n_ji (as the Methods and Formulas section discussed). For m_j approximately the same as n_j (or bigger than), it is a terrible approximation.

In versions 5.0 and 6.0, clogit ALWAYS uses the exact conditional likelihood, so there is no cause for concern when you see the “multiple positive outcomes within strata encountered”—except if you think you should have 1:n_i matched data, in which case you have an error in your dataset.

The new recursive algorithm was not implemented before version 5.0 because it was not well-known.

Often one will see in a text or review that m_j:n_j matching is computationally impossible for anything but small m_j. But this is only true if one uses an enumerative algorithm that steps through all C(m_j+n_j, m_j) possibilities.

The recursive algorithm is proportional to m_j (actually it's the minimum of m_j and n_j), so it gets slower as m_j increases but not unduly.

The bottom line is we strongly recommend anyone doing m_j:n_j matching upgrade to at the current version of Stata and use clogit.