Stream: implementers
Topic: Discharge order vs. event
Matt Rouhana (Oct 08 2020 at 15:53):
Does anyone have any advice on how to capture both the time a discharge is ordered and when the discharge actually occurred?
I'm assuming representing the actual discharge event as Encounter.period.end makes the most sense, but I'm less clear on the discharge order. Utilizing the ServiceRequest Resource makes some sense, but doesn't quite fit the description given in the Boundaries/Relationships section of the documentation:
ServiceRequest is a record of a proposal/plan or order for a service to be performed that would result in a
Procedure,Observation,DiagnosticReport,ImagingStudyor similar resource
None of those Resources would result from the discharge order, unless the discharge itself is considered a Procedure.
Task also seems like a potential fit, but appears to be more commonly used in application workflows. Anyone have a recommendation?
Lloyd McKenzie (Oct 08 2020 at 16:10):
@Brian Postlethwaite
Matt Rouhana (Nov 06 2020 at 14:50):
Still looking for some direction here, if anyone has suggestions. I'm leaning towards either using ServiceRequest or creating an Encounter extension for the time of discharge order.
Eric Prud'hommeaux (Nov 06 2020 at 14:56):
preface to say that I'm not going to have any useful advice, but how are application workflows different from administrative workflows?
René Spronk (Nov 06 2020 at 14:59):
If the only data element missing were to be 'dateTimeOrdered' then an extension may be in order. If you're also capturing who ordered it, if that order could potentially be cancelled or modified, then some separate FHIR resource may be called for. Note that seriveRequest only captures the fact that there is a request, but doesn't actually ask any party to do something, so you'd need Task in addition to ServiceRequest.
Vassil Peytchev (Nov 06 2020 at 16:04):
And to add another wrinkle to this, there are discussions about a Patient Movement resource that would potentially capture more details about a discharge well beyond what is in Encounter.
René Spronk (Nov 06 2020 at 16:08):
That would get my thumbs down - way too exotic to be part of the "80%".
Vassil Peytchev (Nov 06 2020 at 16:27):
"Too exotic" in what sense? Current existing functionality for discharge management seems to be already beyond anything Encounter can manage by itself. Adding ServiceRequest(s) and Task(s) may be able to approximate it, but whether that, or a possible PatientMovement is "too exotic" is hard to determine, I think...
René Spronk (Nov 06 2020 at 16:32):
I'm just speaking from my own experience, so consider my thumbs down a starter opinion (which could change). In some European systems they manage movements, but there are only a very few systems where these would need to be archived. But we may be talking about different "movements" anyway..
Vassil Peytchev (Nov 06 2020 at 16:35):
Yes, "movement" has many different meaning. This is what is under discussion, in early stages...
Matt Rouhana (Nov 09 2020 at 14:55):
Thanks for the feedback. In my case, the only missing element is the time the discharge was ordered, so I think I'm going to go with an extension. In the event that we need to capture additional detail, I'll reconsider.
Last updated: Apr 12 2022 at 19:14 UTC
