Stream: implementers
Topic: lastn GROUP BY Observation.code
Xiaocheng Luan (Oct 01 2019 at 15:17):
Per spec (3rd bullet point under "GROUP BY"):
- "For codes with translations (multiple codings), the code translations are assumed to be equal and the grouping by code SHALL follow the transitive property of equality."
It seems this allows any observation resource(s) to define equality relationship between codings for the purpose of lastn? For example, an observation record from Hospital A has coding [C1, C2], another record from Dr. B's office has coding [C1, C3], and the spec seems to suggest, for the purpose of lastn operation, C1==C2==C3? I must be missing something otherwise the slope is simply too slippery?
Eric Haas (Oct 01 2019 at 15:22):
nope you are not missing anything and it is slippery. how else would you do it?
Xiaocheng Luan (Oct 01 2019 at 18:38):
I would think allowing an observation to appear under multiple coding groups may not be as bad as it sounds, at least everything is still "consistent" with the data, and much can still be done by the client afterwards. The biggest problem with the current spec is that one coding error, or loose coding, or even perfectly correct coding with different levels of angularities could easily throw the whole thing off in unexpected ways. The assumption of equality between codings within a code is already shaky; the transitivity just amplifies it and I don't see a boundary. On top of that, it's challenging to implement, too, it's a dynamic equivalence system.
Grahame Grieve (Oct 01 2019 at 20:48):
yes all that. But as Eric says, what else can be done?
Xiaocheng Luan (Oct 02 2019 at 16:14):
Is there anything that has to be done? As an "outsider" (of healthcare), I think simply grouping by unique coding (system-code pair) might work, though not ideal? Yes, then an observation with multiple coding may fall under more than one groups (duplicates), but I think it's more of an annoyance than an error.
Last updated: Apr 12 2022 at 19:14 UTC
