Stream: research
Topic: Fulfilling a Schedule of Activities
Hugh Glover (Sep 26 2018 at 12:34):
Lets assume the schedule of activities for a study is composed of PlanDefinitions and ActivityDefinitions. We can now integrate that into a CarePlan for a specific patient. The patient then gets an FBC - this will be an Observation.
How do we know that specific Observation is ultimately related to the ScheduleOfActivities and is not in response to an FBC requested elsewhere?
A related question is whether this complexity is better managed through a Workflow rather than a CarePlan?
Lloyd McKenzie (Sep 26 2018 at 14:34):
If the Observation is driven by a PlanDefinition or ActivityDefinition, then it can (and should) point to it with the instantiates extension
Lloyd McKenzie (Sep 26 2018 at 14:35):
Not sure what you mean by "Workflow"
Geoff Low (Sep 26 2018 at 15:18):
I assumed that a need for a particular procedure would translate to a ServiceRequest, the ServiceRequest as an instantiatesCanonical reference to a PlanDefinition - is that what you mean? The Observation would be in response to the ServiceRequest.
Lloyd McKenzie (Sep 26 2018 at 15:42):
The Observation can point to the protocol directly. Whether a ServiceRequest will exist or not may vary, though I agree that will be the typical situation.
Hugh Glover (Sep 27 2018 at 09:02):
The extension is what I need to put in I think. I'll explore that.
The point behind the workflow comment is that I'm looking at this from the perspective of monitoring the execution of a schedule of activities for a specific patient. This is solidly in the request/fulfilment pattern which in the FHIR spec I have read there is a debate as to how this should be done.
Geoff Low (Sep 27 2018 at 10:40):
Yes, so the PlanDefinition instantiates one or more ServiceRequest resources; the ServiceRequest is then instantiated as a Procedure or DiagnosticReport which then lead to Observation; are you asking about the BRIDG view of a Defined/Planned/Performed Activity? A PlannedActivity in this case would be a ServiceRequest with ServiceRequest.intent being plan and a ServiceRequest.status of complete perhaps
Lloyd McKenzie (Sep 27 2018 at 15:08):
It's not so much that there's debate as to how to do workflow as that there's a variety of options and the appropriate option will depend on context. Each approach has pros and cons. Which gets used will depend on both the specific workflow requirements as well as the technical capabilities of the systems. In any event, it's not an either/or situation. If you have anyone asking anyone else to do something, you'll have workflow. Whether you'll have a CarePlan or not depends on whether there's a Patient-specific (and potentially time-specific) pathway defined through the protocol independent of the ordering process.
Geoff Low (Sep 27 2018 at 15:56):
Oh, this I know. This is why I originally suggested using an ODM as an exemplar for the connectathon - the ODM Metadata represents the set of activities (er CRFs) that need to be completed and some ordering on top (Screening Activities precede Treatment activities; blood draws succeed vital signs assessments, etc) - this is how these are currently defined in Electronic Data Capture systems (aligned with the Schedule of Activirties from the Protocol). Where it gets hazy is the paths to be followed, say if the arms have different activities associated; the SDM was incepted to handle much of that (and is based broadly on the BPMN2 specification).
Where it gets interesting is if for example we define a ProcedureRequest of contrast-MRI and the EHR/Hospital system is aware of scheduled downtime for regassing etc of the MRI at some point hence; then we can avoid protocol deviations by not allowing recruitment of patients based on the windows entered in the CarePlan/PlanDefinition.
This topic is really interesting, I wish I could be there to scrum on it.
Hugh Glover (Sep 27 2018 at 16:48):
What this picks out for me is the different interpretations that can be placed on the apparently simple use case. Representing a schedule of activities as a general plan is easy enough - its when you start trying to use it that we get the "well you could do this or you could do that". What I'm hoping to do is better understand the options and justifications, then maybe in January we can try a real data transfer for a specific case.
Geoff Low (Sep 27 2018 at 17:00):
And here arises the need for an implementation guide. We decide what works best, fix what needs fixing and then roll out the way forward. I've been too academic with some of this work in the past, and Transcelerate are really pushing to get stuff out there is a great motivator. Are you meeting off cycle about this project as well?
Hugh Glover (Sep 27 2018 at 17:20):
If we can raise enough interest I'd hope it will become a regular BR&R topic - it does need participants though ...
Geoff Low (Sep 27 2018 at 21:43):
I volunteer, and would be happy to co-lead with someone (obv. not representative of an evil vendor corporation like me).
Last updated: Apr 12 2022 at 19:14 UTC
