(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.
This same problem was addressed in HL7v2: http://www.ringholm.de/docs/00810_en.htm
Relevant Jira Issues
Relevant Meeting Minutes
Work in Progress
What counts as a Movement?
There are two categories of "movement"
- Administrative movement (e.g. Admit, Transfer, Discharge)
- Physical movement (e.g. RTLS movements).
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)
Admission with inpatient appointments
- Patient arrives at the ED (new encounter, first movement)
- Patient is admitted to the ICU (new or same encounter, first movement for new encounter, second movement for the overall episode)
- 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)
- Patient improved and is moved to the main floor for observation (same encounter, fourth movement)
- Patient recovers and is discharged (same encounter, fifth movement)
ED Arrival then Departure
- Patient is admitted through the ED (new encounter, first movement)
- Patient leaves immediately (same encounter, second movement)
Leave of Absence
- Patient admitted to long term care (new encounter, first movement)
- 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)
- 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)
- Patient arrives at an outpatient clinic
- Patient has an x-ray done at an in-clinic imaging center
- Patient has a lab draw at an in-clinic lab
- Should Movement allow multiple Encounter references to handle transitions between Encounters. E.g. moving from a primary encounter to a child encounter and back?
- How should we handle Leave Of Absence scenarios?
- Should encounter status history be included in the Movement?
- Should participant history be in scope? May be useful for some EU countries?
- Should the scope of Movement include RTLS (realtime location services) style movements?
- What triggers a movement?
- Will the from to/from details of a movement be included? (such as movement from ward 1 to ward 2)
- Should how are bed swaps to be handled?
- 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?
- Transferring a patient between facilities?
- Is the Movement a list of locations, or is it the actual movement between locations?
- Is the duration the time at the location or the duration between the locations? (This may be relevant for things like billing)
- Should there be an implied "responsibility" during a movement?
- 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.
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
Contact the Learning Health Systems group (Russ Leftwich) to see if the CareTeam interactions with this resource should be considered.