FHIR Chat · Observation - split episode context from encounter context

Stream: implementers

Topic: Observation - split episode context from encounter context

Lloyd McKenzie (Aug 09 2018 at 19:01):

This is almost too late, but I figured I'd raise it. Right now the workflow pattern for Observation.context is 0..1 Encounter|EpisodeOfCare. That's always made me slightly uncomfortable. The notion of 0..1 Encounter is fine. A given Observation should be "owned" by no more than one Encounter. However, it's possible a single Observation could be relevant to multiple episodes. I.e. It could be tied to your pregnancy and also to your hypertension management. (And of course also to your encounter.) Would we be better splitting ".context" into ".encounter 0..1 Encounter" and ".episode 0..* EpisodeOfCare"?

Lloyd McKenzie (Aug 09 2018 at 19:02):

This is our last chance to do this for Observation.

Lloyd McKenzie (Aug 09 2018 at 19:02):

We'd presumably make the same change everywhere else .context currently appears, but that wouldn't have to happen before ballot.

Grahame Grieve (Aug 09 2018 at 19:03):

it does sound like an extension thing to me

Rob Hausam (Aug 09 2018 at 19:15):

Lloyd is exactly right about this from a healthcare systems theory (for lack of a better term that comes to mind at the moment) perspective. A single observation certainly can and should be able to reference multiple "episodes of care", but logically only one encounter. If there are systems that actually implement the notion of "episode of care" as it was intended they would have this requirement. What I'm not as certain of is exactly how well or thoroughly most systems are implementing this. In principle I think that having encounter 0..1 and episode 0..* would be better. If you just add an extension then you still have .context and I expect there would be both some redundancy and lack of clarity in regard to using it (or suggesting to not use it) along with the extension.

Lloyd McKenzie (Aug 09 2018 at 19:25):

The trick is that both Encounter and EpisodeOfCare have been deemed to be core. Supporting additional Episodes as extensions is somewhat messy. My guess is that we'll probably change the pattern to what I've described for all the other resources. The question is what whether we want (and can) do that for Observation too.

Eric Haas (Aug 09 2018 at 20:26):

I agree with Lloyd conceptually.
but I am not sure how we do this process wise.. Our OO meetig was 2 + hrs ago.

Eric Haas (Aug 09 2018 at 20:30):

what about an encounter sans Episode of Care and and extension for Episodes?

Lloyd McKenzie (Aug 09 2018 at 20:50):

I was actually about to propose the same. Rename Observation.context to Observation.encounter, type it as 0..1 Encounter and define an extension applicable to Observation (and eventually all requests and events) for a 0..* link to EpisodeOfCare. That probably accurately reflects current support.

Lloyd McKenzie (Aug 09 2018 at 20:51):

Process-wise, I could submit a change request that could be pre-applied before ballot. In theory if someone negative balloted and forced things back to the way they were, that would prevent us from passing Observation as normative. However, given that we're actually expanding capability rather than diminishing it and given that I don't think anyone's actually using EpisodeOfCare yet, I think the chances of that happening are super-slim.

Lloyd McKenzie (Aug 09 2018 at 20:52):

Would be best to at least ensure the majority of the OO co-chairs are onside with the change.

Eric Haas (Aug 09 2018 at 20:55):

@Rob Hausam ? @Riki Merrick ? @Hans Buitendijk ? @Lorraine Constable ? ( will need to email the rest)

Rob Hausam (Aug 09 2018 at 21:52):

That seems workable to me.

Brian Postlethwaite (Aug 10 2018 at 02:19):

Is there an implication on the search parameters also?
(p.s. I like the idea of splitting the encounter/episode refs on obs and the suggested cardinalities also)