FHIR Chat · Encounter diagnosis/indication · implementers

Stream: implementers

Topic: Encounter diagnosis/indication


view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 00:54):

There is a task 10544 on encounter where we are refactoring the diagnosis links which also removed the link to procedure as an indicator (there is a similar task for EpisodeOfCare too)
I was wondering if this was a reasonable thing to have removed the procedure, as I don't think that's enough information to put in as a reason for the encounter. I would have expected that you would need to provide more detail as to why the procedure required a followup encounter (capturing the details of the complications that arose from the procedure - which is the purpose of the condition, and admitting diagnosis on the encounter)
Comments @Michelle (Moseman) Miller, @Lloyd McKenzie others?

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 00:56):

While I'm asking anyone got a clinically valid example we can include in the spec for a condition that resulted from a procedure (so I can reference in my example)
Thanks all

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 14:34):

From your listserv email, @Brian Postlethwaite , you recommended:

1. Move reason codableconcept into backbone element and make diagnosis.condition 0..1
2. Remove the extension for primary diagnosis completely
3. Introduce the text above discussing primary diagnosis
4. Provide guidance on appt.indication -> encounter.diagnosis[role=admission] and new condition resource as needed
5. Rename moved reason property diagnosis.reason to diagnosis.code (and include an alias for reason)

Also, part of GF#10544 resolution was

The description on the reason property will be updated to indicate that its purpose as a more patient
centric valueset/concept

I agree with having a reason that can be codified or a reference, but does this mean the reason (to be included in the BackboneElement) could be patient reason or provider determined diagnosis?

@Brian Postlethwaite , your PA listserv email also said:

The extension for primary diagnosis I’d like to explain that this concept is represented by the diagnosis with role = “admitting diagnosis”

I don't think that the admitting diagnosis is always the primary diagnosis (for billing purposes).

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 14:35):

That last part, sorry also meant to include having a rank of 1 too

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 14:36):

The changes from the trackers have all been applied, so you can see how my suggestions would apply overtop.

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 14:40):

OK, I'll take a look at the applied changes....one sec

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 14:42):

Part of GF#10544 resolution was to remove the extension (The encounter-primaryDiagnosis and encounter-relatedCondition extensions will be removed, as they are now redundant, and represented in the core resource.), which was consistent with your recommendation #2, but I still see the extension in current build.

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 14:50):

That's due to the not being able to use the coded reason as a primary diagnosis, and there were 2 examples doing that, and I wanted to ensure that everyone was good with the admission diagnosis *requiring* a condition resource, and not just a coded reason.

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 14:53):

I think I'd rather allow the BackboneElement to support a code or reference, so we can remove the extension as originally planned. To me, we just need to clarify if the reason can be either a patient expressed reason for a practitioner's admission diagnosis (in coded form)

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 14:54):

You may need some invariant that says either condition (reference) or code (reason) are required since Encounter.diagnosis.condition is currently 1..1

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 15:13):

That is where I wanted to go.
Are you happy that the reason is that thing, and moving it in the backbone diagnosis makes sense to you?

view this post on Zulip Michelle (Moseman) Miller (Feb 19 2017 at 15:27):

As long as the definition of reason implies it could be either patient reason and/or practitioner reason. When it is a patient reason, there might not be a role or rank as that is typically determined by practitioners

view this post on Zulip Brian Postlethwaite (Feb 19 2017 at 15:45):

Or there is a role specifically for patients to select...
(currently example binding - but could include a patient self-diagnosis value in there)


Last updated: Apr 12 2022 at 19:14 UTC