FHIR Chat · Encounter.length · implementers

Stream: implementers

Topic: Encounter.length


view this post on Zulip Aditya Joshi (Oct 15 2018 at 17:55):

How to represent "expected length of stay" in case of inpatient admissions in FHIR Encounter resource?

Encounter.length seems best option but definition states- "Quantity of time the encounter lasted."
It seems that it meant for admission time lapsed, this is useful at the time of discharge as at that time, one will know what was exact length of stay. But how to represent "expected" length at the time of admission.

I think Encounter.length should work for both use cases- expected v/s actual length. If no discharge date then probably expected length. But not so sure. Any thoughts or help would be much appreciated.

view this post on Zulip Lloyd McKenzie (Oct 15 2018 at 18:51):

@Brian Postlethwaite ?

view this post on Zulip Brian Postlethwaite (Oct 15 2018 at 21:54):

There is also the period which I would have expected to be used.
What is your use case for expected length of stay?

view this post on Zulip Aditya Joshi (Oct 16 2018 at 11:40):

Thanks @Brian Postlethwaite for your reply.

My use case is to send "expected length of stay" of Patient in hospital from Provider to Insurer.

Context: Provider sending Authorization request (pre authorization) for some services. This is done by using Claim resource (claim.use="proposed"). This pre auth request is for patient admitted in hospital. Request should contain expected length of stay, for example, doctor feels that Patient would be admitted for 3 days. So, admission is started but not yet completed, we know start date but there is no end date.

Using Encounter.period = it says that you can omit period.end if not known. Can we use a future date here to notify receiver that it is expected discharge date.

Using Encounter.length= Quantity of time the encounter lasted (less time absent). This means it contains time period which has already lapsed or occurred, so probably can't use for expected length.

Using Claim.hospitalization =
The start and optional end dates of when the patient was confined to a treatment center.
Definition states that it is also a period which is already lapsed.

There could be another interesting requirement when Provider is sending actual Claim and there he wants to send "expected length of stay" (what he projected at the beginning of admission) and "actual length of stay" (admission date to discharge date). Actual stay can be easily shown using Encounter.period (start and end dates). But not sure about "expected length of stay".

view this post on Zulip Aditya Joshi (Oct 19 2018 at 11:01):

Hi @Brian Postlethwaite waiting for your kind response.

view this post on Zulip David Riddle (Apr 03 2019 at 14:13):

@Brian Postlethwaite , @Andy Stechishin and @Paul Knapp,

Do you have any recommendations on how best to convey the actual admission and discharge date for an inpatient stay via. the R4 Claim resource? I view admission and discharge dates as Claim level vs. Claim.item level/line level attributes of a Claim. Since Claim.hospitalization from STU3 is no longer supported in R4, what R4 element supports the ability to indicate 'The start and optional end dates of when the patient was confined to a treatment center' that was supported via. Claim.hospitalization in STU3? cc @Michelle (Moseman) Miller

view this post on Zulip Lloyd McKenzie (Apr 03 2019 at 14:14):

Why wouldn't you use the referenced Encounter?

view this post on Zulip David Riddle (Apr 03 2019 at 14:35):

@Lloyd McKenzie , As I indicated, admission and discharge dates have traditionally been viewed as Claim level vs. line/item level attributes of a claim. Since the encounter element is at the line/item level (Claim.item.encounter), I was struggling a bit to understand which line/item's encounter would be populated with the admission and discharge dates. Based on your suggestion, it sounds like all of the Claim.items on an Inpatient claim would repeat references to the same encounter and thus the same encounter.period. I was trying to understand if that was the thought behind removing support for Claim.hospitalization which allowed the admission and discharge dates to be established at the Claim level vs. repeating them for each line/item associated with the claim.

view this post on Zulip Andy Stechishin (Apr 03 2019 at 14:56):

@David Riddle you can link an Encounter from the Claim.supportingInfo.valueReference which would place the reference to the Encounter at the Claim level. If you have an Encounter this would be the recommended approach. If you only have the admit and discharges dates, you would use the Claim.supportingInfo.timingPeriod

view this post on Zulip Paul Knapp (Apr 03 2019 at 15:11):

@David Riddle Agree with Andy's comment above, the supporting Info supports the inclusion of claim-level and line-level information where that information may be simple and complex types (hospitalization or employment Impacted periods, initial onset or other dates, etc.) or FHIR resources or other materials.
Hospitalization would have .supportingInfo.category='hospitalized' and .supportingInfo.timingPeriod to convey the admit and/or discharge dates.

Also, FM is leaning toward including the Encounter via supportingInfo rather than having it specified directly at the line level.

view this post on Zulip David Riddle (Apr 03 2019 at 18:14):

@Andy Stechishin and @Paul Knapp , Thank you both for your guidance on this. I may have additional questions, but this is very helpful.

view this post on Zulip Andy Stechishin (Apr 03 2019 at 20:55):

You are welcome, and asking and answering questions (simple ones anyways) is what this forum is all about


Last updated: Apr 12 2022 at 19:14 UTC