Overview

(paraphrased from FHIR-14157)

The current Encounter resource has several issues:

• the history of state, class and location, although changing in parallel most of the time, are kept separate, making it hard to see the "whole picture" of what has changed.
• the mechanisms of keeping history of class/status and location are inconsistent
• it is currently very difficult to add extensions that need tracking, as this would require multiple or complex extensions to keep both the current value as well as the history
• for long stay patients (>2 years), the amount of historical data tracked in the classHistory, statusHistory, and location properties can be massive, making the Encounter very large

PA has been considering refactoring Encounter, such that the Encounter resource would represent only the most recent information for the encounter.  Historical statuses, locations, and classes would be on a series of Movement resources.  We anticipate that many systems likely only need the current information, an could continue to use Encounter for that.  Systems that need to track historical information about the encounter would be able to invest in the added complexity of processing Movements.

Note that this historical information is different than what is tracked in the versions of the Encounter resource.  Past movements of a patient are often updated after the fact to correct what actually happened.  Additionally, there are some future pending movements, such as a pending admit or pending transfer, which may be handled in the proposed Movement resource.

FHIR History doesn't cater for this need as the information isn't always accurate and can be corrected/back populated too.

Related Projects

This same problem was addressed in HL7v2: http://www.ringholm.de/docs/00810_en.htm (Z99 / ZDT)

Relevant Jira Issues

FHIR-13702 - Getting issue details... STATUS

FHIR-14157 - Getting issue details... STATUS

FHIR-22485 - Getting issue details... STATUS

FHIR-22767 - Getting issue details... STATUS

FHIR-23837 - Getting issue details... STATUS

FHIR-17303 - Getting issue details... STATUS

Relevant Meeting Minutes

2019JanWGMMinutes-TuesdayQ1

2019SeptWGMMinutes-TuesdayQ1

2019SeptWGMMinutes-ThursdayQ3

2019-10-23 Conference Call

2020FebWGMMinutes-ThursdayQ1

2020FebWGMMinutes-ThursdayQ2

2020SeptVirtualWGMMinutes-MondayQ2

<Sept 2021 WGM - OO Thurs Q3>

Work in Progress

encountermk2-spreadsheet.xlsx

Cooper Thompson 1/18/2022 3:16 PM

Updated version of the spreadsheet based on discussion during Jan 22 WGM Tues Q3

What counts as a Movement?

There are two categories of "movement"

• Administrative movement (e.g. Admit, Transfer, Discharge)
• Physical movement (e.g. RTLS movements).  

Cooper Thompson 9/23/2021 1:39 PM

Physical movement is a common issue that OO is working on via their Transport resource.  

Administrative movement is specific to Encounter, however, other resources may also have a status/class/location "history", so we should consider making our "EncounterHistory / Movement" resource a pattern, and having the PA EncounterHistory be the first instantiation of that pattern.

In scope for the Movement

• The initial arrival of the patient from outside of the health system.
• Any time a patient moves from one location in the health system to another.
• The departure of the patient from the health system.
• Status and class changes may also trigger a Movement, even if the patient doesn't "move".
  • E.g. the patient is moved from an Inpatient to Observation status, but stays in the same bed

Including the "bookend" scenarios (initial arrival, final departure) as Movements makes the data model simpler.  Otherwise, systems that care about Movements would need to look to the Encounter for the initial and final times, and Movement for everything else.  By including the arrival and departure events, systems that are interested just look at at Movements.

In Limbo for Movement:

Out of Scope (tentatively)

• RTLS level location changes (e.g. patient wanders down the hall to a vending machine)
• Device tracking (e.g. a blood pressure monitor is given to a patient for home monitoring)
• Specimen tracking (e.g. hospital collects specimen, transfers it to courier, who transfers it to a lab)

Stories

Admission with inpatient appointments

1. Patient arrives at the ED (new encounter, first movement)
2. Patient is admitted to the ICU (new or same encounter, first movement for new encounter, second movement for the overall episode)
3. Patient goes to radiology for an X-Ray (a new child encounter that is "part of" the main encounter, first movement for the child encounter, third movement for the overall episode)
4. Patient improved and is moved to the main floor for observation (same encounter, fourth movement)
5. Patient recovers and is discharged (same encounter, fifth movement)

ED Arrival then Departure

1. Patient is admitted through the ED (new encounter, first movement)
2. Patient leaves immediately (same encounter, second movement)

Leave of Absence

1. Patient admitted to long term care (new encounter, first movement)
2. Patient goes to a nearby hospital for weekly dialysis. (new encounter, two movements:  one to depart the LTC, one to arrive at the dialysis clinic)
3. Patient returns to the long term care facility (two movements: one to depart the dialysis clinic, one to return to the LTC)

Outpatient (Non-Acute, GP, etc.)

(to ensure that if refactoring occurs data required for primary care is still possible)

1. Patient arrives at an outpatient clinic
2. Patient has an x-ray done at an in-clinic imaging center
3. Patient has a lab draw at an in-clinic lab

Encounters in an Emergency followed by Admission to a Ward then Discharge 2 days later

Encounters in an outpatient procedure - e.g. colonoscopy

Encounters in a GP clinic

Questions

1. Should Movement allow multiple Encounter references to handle transitions between Encounters.  E.g. moving from a primary encounter to a child encounter and back?
2. How should we handle Leave Of Absence scenarios?
3. Should encounter status history be included in the Movement?
4. Should participant history be in scope?  May be useful for some EU countries?  
5. Should the scope of Movement include RTLS (realtime location services) style movements?
6. What triggers a movement?
7. Will the from to/from details of a movement be included? (such as movement from ward 1 to ward 2)
8. Should how are bed swaps to be handled?
9. Would something like transport recording taking patients on an outing such as to a shopping center in aged care or disability be covered by a movement?
10. Transferring a patient between facilities?
11. Is the Movement a list of locations, or is it the actual movement between locations?
12. Is the duration the time at the location or the duration between the locations? (This may be relevant for things like billing)
13. Should there be an implied "responsibility" during a movement?
14. The Movement should be able to cater for "planned" movements - e.g. planning to move to a ward or imaging etc

Should we compare this resource to the data we experience from package delivery tracking?

Movement Resource Design notes

Orders and Observations considered creating a complete resource that would capture a more complete set of metadata around these events.

Task profile?

Conditions under which the movement took place - environmental

From a patient administrative perspective this could include other requirements for the movement to occur, such as wheelchairs, PPE, ...

Patient Transport could also fit into this space to transfer between facilities

Would the resource record both source, and destination locations - the existing encounter model doesn't cater for this, apart from checking the previous location, and the current.

Would want to be able to be planned, recorded, and amended (to correct data if required)

Do we need to force these to be the same concept? And let both exist, and provide guidance on how they are different.

Types of movement? Specimen, ADT Patient movement, change class movement, patient transport meeting

TransportEvent Resource Proposal - FHIR - Confluence (hl7.org) is the O&O name suggested there

The Specimen metadata includes some information about requirements - likely boundaries such as a temperature are in there, nothing at present around recording actuals so that you could record an infraction from the constraints required - which could result in a specimen being unusable.

ServiceRequest - order something to be done

Task - tracks the doing of the service request

Movement/TransportEvent - additional constraints around the actual event - does this also become both a planned and actual thing?

Supply Movement is another potential usage of this concept.

Meals on wheels - delivering meals to aged in the home.

This leaves a question should we be replacing the content in the Encounter, or just leave that as a significant summary, or light weight version where the full movement event context isn't needed. - Keeping the existing elements is most likely as now.

To get the properties for this resource, expect that we'll need to prototype each of the above use cases to identify common properties, and then refactor into profiles with a common 80% where we can 

Utilizing the movement for contact tracing may be appropriate, although outside the scope, as who is there might not be covered.

The discussion lead to this potential relationships diagram

This is the modeling done in Germany to represent the different levels of "Encounters".

1. The overall IP admission
2. The patient's movements through different units during the admission.

Contact the Learning Health Systems group (Russ Leftwich) to see if the CareTeam interactions with this resource should be considered.

PA Jan 22 WGM - Tuesday Q3

Encounter:

    .identifier
    .status
    .class
    .type
    .serviceType
    .priority
    .subject
    .subjectStatus
    .participant
    .appointment
    .period
    .length
    .reasonCode
    .reasonReference
    .diagnosis
    .account
    .location
    .serviceProvider
    .partOf

The actual updates to Encounter involve removing:

    .statusHistory
    .statusHistory.status
    .statusHistory.period
    .classHistory
    .classHistory.class
    .classHistory.period

EncounterHistory

    .identifier
    .status
    .class
    .type
    .subject
    .subjectStatus
    .period
    .length
    .location
    .partOf

Other changes:

• Move specialArrangement out of hospitalization to a top-level Encounter
• ?Remove dietPreference from Encounter, create extension that is allowed on Encounter and Patient.  Discuss with Patient Care.
• Move specialCourtesy out of hospitalization onto a top level Encounter property.  Update the specialCourtesy definition to differentiate from the security label tag that has a VIP value.  https://build.fhir.org/valueset-security-labels.html
• Update special-arrangement search param to point of the new location of specialArragnement.

  Consider new tracker to handle patient preferences more generally?