(paraphrased from FHIR-14157)
The current Encounter resource has several issues:
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
2019-10-23 Conference Call
There are two categories of "movement"
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.
(to ensure that if refactoring occurs data required for primary care is still possible)
Should we compare this resource to the data we experience from package delivery tracking?
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.