FHIR Chat · Planned and booked admissions · implementers

Stream: implementers

Topic: Planned and booked admissions


view this post on Zulip Martin Grundberg (May 22 2019 at 15:21):

We have been looking into how to represent a planned and booked admission (to be admitted to a ward as an inpatient). If you look at an IP waiting list, this could be one of the rows.

As a comparison, a planned or booked appointment can both be represented using the Appointment resource. This may later result in a visit to the hospital (Encounter resource).

How should we represent:
1. A planned admission (no admission date decided, but on an IP waiting list)
2. A booked admission (an admission date/TCI date has been decided, likely also the ears
Our initial idea was/is to use the Appointment resource also for this, and create an Encounter on admission. Is this correct?

Or should Appointment be seen as only for outpatient settings, and not a planned/booked ward stay? If so, what resource should be used?

Thanks!

view this post on Zulip Lloyd McKenzie (May 22 2019 at 15:26):

@Brian Postlethwaite ?

view this post on Zulip René Spronk (May 23 2019 at 06:52):

Encounters are meant to be used for any kind of encounter. The description of Encounters states that this covers the life cycle of encounters starting with the pre-admit. Encounter.status has the option 'planned' and as such would go a long way.
In general the use of scheduling resources like Appointment would only add value if you're really doing resource scheduling, with schedules/blocked slots. etc. Appointment.status does have a 'wait-list' value, and in effect that status is the one you'd need prior to a pre-admit or admit.
So, IMHO, waiting-list = Appointment, booked admission = pre-admit = Encounter.

view this post on Zulip Lloyd McKenzie (May 23 2019 at 14:48):

@René Spronk Pre-admit is intended for situations where you're doing billable work against the encounter before the actual admission. This could include pre-admission paperwork, room preparation, etc. It's not intended to act as a placeholder for a visit that's scheduled. Appointment supports both proposed and booked appointments. Proposed appointments can exist that don't have a time/date specified. So I would lean towards Appointment, status=proposed, no dateTimes for wait-list and Appointment=booked for booked admissions.

view this post on Zulip René Spronk (May 23 2019 at 14:57):

Hmm. Encounter.status being planned means just that - planned (according to the value set, and the text for the Encounter resource). In your context that could be the equivalent of a pre-admit (and financial stuff) but it needn't be.
Yes, you could do an Appoint with status 'proposed' without any date/time, and that would be kind of a waiting list. Given that there is an explicit status code 'wait-list' for Appointment that's probably a better fit than 'proposed'. Proposed has all sorts of workflow consequences for scheduling applications, it's meant to trigger them to create AppointmentResponses.

view this post on Zulip Lloyd McKenzie (May 23 2019 at 16:03):

Ah. Missed waitlist - that's definitely a better status. "Encounter instances may exist before the actual encounter takes place to convey pre-admission information, including using Encounters elements to reflect the planned start date or planned encounter locations. In this case the status element is set to 'planned'." That's not the same as a wait-list scenario. That said, we should wait for a response from @Brian Postlethwaite as his work group is responsible for both resources.

view this post on Zulip Martin Grundberg (May 24 2019 at 13:38):

Very good and useful input!

To summarize a bit, and this makes sense to me:

  • Encounter.status=planned is intended for pre-admission activities occurring before the patient arrives to the hospital, and those could be billable.
  • Appointment.status=waitlist is intended for a patient that is waiting for an appointment to be booked but no time is yet decided
  • Appointment.status=booked is intended for a patient who has received a time for their appointment, and also then a TCI date for admission.

To me this makes sense, and it also clearly divides the responsibility between the planning/booking phase (belonging to the Appointment), and the outcome phase (what is actually done, belonging to the Encounter).

Scheduling of resources is also very important. And In my head, that belongs to the Appointment (which is also what @René Spronk is getting at), even for IPs as I would see bed capacity as a resource that is needed in a similar way as I would see a doctor being needed for an OP appointment. Do you share this view?

I also feel there are benefits with using Appointment for both OP and IP as you can work with the same resources in your planning phase. If you need to book a ward stay, you look at Appointment with status=waitlist, same as you would for an OP appointment.

It is also important to be able to differentiate planning from actual outcome data. The intended planned length of an appointment needs to be separated from the duration of the encounter. Using Encounter.period together with Encounter.status=planned for the intended length of stay is not a good idea as that will get overwritten with the actual start/end when the encounter starts (status=arrived/in-progress).

The actual use case we are looking at now is an elective surgery. It seems clear that an Appointment is needed in a room at the surgery department, but we are considering whether to have a separate Appointment for the ward stay as they likely are not always planned and booked together (appointment for procedure could be booked, but there are no beds available to book at the ward, or vice versa).

view this post on Zulip René Spronk (May 24 2019 at 13:54):

As for you summarization, I'd agree with those resources and status codes shown at the top of your post (but mind you, we haven't heard from the actual working group responsible for these resources).
https://vimeo.com/305046230 is an intro level tutorial about scheduling. Scheduling has a wide range of functionality, and involves all sorts of resources, one of which may be the patient (but there doesn't have to be a patient at all). Appointment is for IP, OP, telephone call, skype consult, surgery, or whatever else you can think of.

view this post on Zulip Lloyd McKenzie (May 24 2019 at 14:56):

It's certainly possible to book multiple appointments for an overall event if you need different "resource sets" for different slots. (The surgical suite would need to be booked for a different period of time than the recovery room or the ward)

view this post on Zulip Brian Postlethwaite (Jun 25 2019 at 09:45):

All the above makes sense. :grinning_face_with_smiling_eyes:
Making it easy for me.


Last updated: Apr 12 2022 at 19:14 UTC