Stream: implementers
Topic: How to use Timing with CommunicationRequest
Nikolai Schwertner (Jul 15 2021 at 11:37):
I am working on a use case where a patient gets repeat reminders (let's say to take his pills every day at 2pm). I am thinking that the scheduled reminders could be expressed as CommunicationRequest resources and the actual notifications as Communication resources. The only issue is that the CommunicationRequest does not support Timing in theoccurence attribute (only DateTime or Period is supported) and this cannot express a communication request that repeats in time. It might be possible to set up some ActivityDefinition resource to express the reapeat timing for the reminders, but that seems too complex for this otherwise simple use case (repeat reminders to patient). Does anyone have any thought as to what a reasonable approach might be based on CommunicationRequest (for example, implement an extension to support observationTiming attribute)?
Lloyd McKenzie (Jul 15 2021 at 14:09):
If you're saying "please do" in the reminder, that should be a Task. It's a "to do" item that could be marked as complete or not (with a reason). CommunicationRequest is "please share specific information with a particular recipient". The notion of sharing the same piece of information on a regular schedule didn't really make sense so Timing wasn't included. If you really wanted to go that route, an extension and/or a change request would be necessary.
Nikolai Schwertner (Jul 15 2021 at 21:35):
Thank you for the perspective, Lloyd. I initially looked at Task as a potential solution for the reminder, but couldn't figure out a good way to express the repeatable timing of the action (the instantiatesCanonical argument feels strange to use for expressing repeat timing) and it is not clear how one can record the result of each iteration (separate Task for each iteration perhaps, but then how do we express the generator+timing of that series?). Is there an example somewhere of using Task as repeat reminders mechanism?
[I thought that CommunicationRequest might work out because the documentaion talks about reminders and notifications use cases...]
Lloyd McKenzie (Jul 16 2021 at 15:03):
Typically Task wouldn't handle the repetition bit - you'd have one Task per repetition - which would be done or not done. The order saying "please do" would typically be a MedicationRequest, given that you're dealing with medications. You could spawn off an instance order for each occurrence if you wished.
Nikolai Schwertner (Jul 16 2021 at 20:31):
It could be other events triggering the reminders series also (need to enter measurement data, etc), but the general idea still applies - an Order resource could express the reminders schedule and the results tracked via Tasks. Thank you very much for explaining.
Last updated: Apr 12 2022 at 19:14 UTC
