One can build such schemes from lattices, though there is a great deal of nuance that must be taken.
The high-level idea of the construction is as follows.
The following is true for essentially all lattice-based schemes (all I know, which is quite a few), namely for a (matrix) ciphertext $C$, there is an appropriate (vector) secret key $s$ such that
$$C^ts = \mathsf{error\_correct}(m) + e$$
where $m$ is the message, $e$ is the error.
Here, $\mathsf{error\_correct}(m)$ is some procedure that allows one to recover $m$ from the (noisly encoded) message $\mathsf{error\_correct}(m)+e$.
The most common way is to write $\mathsf{error\_correct}(m) = (q/2)m$, and then divide by $(q/2)$ and round to the nearest integer.
There are other techniques possible though.
One can replace "matrix" and "vector" with other algebracially structured things, i.e. module elements over some ring. I won't bother.
This "linear decryption" structure is the basis of all of the homomorphic properties that lattice-based schemes have (though it isn't sufficient by itself --- code-based schemes can often have a similar structure, but we can't build FHE from them).
Anyway, it can also be used to build threshold encryption.
The idea is to use some linear secret-sharing of $s$, say $s = \sum_i a_i s_i$.
We then can write
$$C^ts = C^t(\sum_i a_i s_i) = \sum_i (a_i C)^ts_i.$$
I.e. each participant computes (local) decryptions of $a_i C$, where $a_i$ are the coefficients determined by the linear secret-sharing scheme.
One can then sum the resulting "partial decryptions" to get the full decryption.
There are two nuances to take care of here though
Computing $a_i C$ increases the error from $e$ to $a_i e$. This might overwhelm the error-correction. This can be fixed by using secret-sharing with small (say $\{0,1\}$) coefficients, or appealing to lattice-based schemes that admit efficient multiplication by large scalars.
The partial decryptions $\lfloor a_iC^ts / (q/2)\rceil$ may leak information about the error $e$, which can cause security issues. This can also be fixed in several ways, the simplest is to add additional error $e_{\mathsf{large}}$ (often called "smudging" or "flooding" error) such that $e_{\mathsf{large}}+e$ is hard to distinguish from $e_{\mathsf{large}}$, i.e. it "hides" the sensitive error $e$.
After fixing things in the above way
- decryption is non-interactive, and
- can be processed "in-line" as you want. Namely, the $i$th party takes the currently being processed decryption $c$, and sends $c + (a_i C^t s_i + e_{\mathsf{large}})$ to the next party. The final party then computes $c\mapsto \lfloor c / (q/2)\rceil$.
