Stream: implementers
Topic: Appointment cancellation time
Domenico Corapi (May 13 2020 at 14:29):
Where would you store the time of an appointment cancellation? I could not find an obvious spot in the Appointment and the AppointmentResponse resources
Lloyd McKenzie (May 13 2020 at 17:07):
@Brian Postlethwaite
René Spronk (May 13 2020 at 19:51):
In the Provenance resource?
Domenico Corapi (May 14 2020 at 09:14):
Thanks for the suggestion, Provenance might work.
Although the problem in our specific case is that we are already generating a Provenance object whose timestamp refers to when the cancellation was received/processed rather than when it happened (could have been on a phone call actioned by an operator). We could create another provenance resource and use something like the agent in order to differentiate, but we are also considering using an extension for it.
Lloyd McKenzie (May 14 2020 at 13:35):
@John Moehrke
John Moehrke (May 14 2020 at 13:49):
Yes you could have a Provenance that is specific to the canceling event, vs when it was received.
Although I am the Provenance advocate, this canceling time seems like it is fundamental enough to appointment typical (not normal) flow. So I would advocate for the canceling time to become an element in the Appointment, along with cancelingReason that is already there. The FHIR modeling for Provenance recognizes that sometimes an element of Provenance is so critical to the resource being designed that it needs to be represented in the resource (e.g. author).
This said, I am not an expert in the art of appointments.
René Spronk (May 14 2020 at 13:53):
One of the problems being that the cancellation time will be be relevant from a 'storage' perspective, but less some from an interoperability perspective. FHIR is an interoperability standard, right ? ;-)
Domenico Corapi (May 14 2020 at 15:07):
Also not an appointment expert but my view here is that a cancellation time is on par with the "cancellation reason" and "created" fields from an interoperability perspective
John Moehrke (May 14 2020 at 15:10):
I think it is interop relevant as it indicates when the cancellation happened. Which would be needed to understand state change.. It could be considered something that should be recorded in a communication record that held the cancelation. right?
Vassil Peytchev (May 14 2020 at 15:18):
It could be considered something that should be recorded in a communication record that held the cancelation. right?
That is stretching it too far out, IMO.
Brian Postlethwaite (Jun 22 2020 at 04:53):
Wouldn't be using the modified value when that content was defined in the history, and for what purpose are you looking to use the value?
Medi Harsini (Jul 14 2020 at 20:42):
Most of status-based resources should have to deal with this as a requirement... perhaps statusDate rather than having distinctive element related to each status
Last updated: Apr 12 2022 at 19:14 UTC
