Stream: research
Topic: Associating Observations with a Trial
Gustav Vella (Aug 05 2021 at 12:26):
Hi there,
given a situation where..
-
it is not possible to reliably infer the observations for a patient related to a Trial on the basis of time and observation-metadata, references to an encounter or whatever criteria...
and -
the customer is willing to change their process allowing their central Service-Request-Application to add the trial ID whenever they send a trial related service request...
Where would you put - or rather - how would you represent that trial ID in a FHIR Resource?
- In the ServiceRequest itself? (I don't see a decent place for putting the ID)
- by referencing from ServiceRequest to a CarePlan which (In this case we use the
based-on
reference) - which via extension points to ResearchStudy containing the Identifier (Business Identifier for study)? . - Something completely different if none of the suggestions make sense and I'm completely off the mark?
Lloyd McKenzie (Aug 05 2021 at 14:56):
There's a standard extension that allows many resources to be tied to a ResearchStudy (http://build.fhir.org/extension-workflow-researchstudy.html). ServiceRequest isn't in that list yet, though it should be. Care to submit a change request?
Gustav Vella (Aug 05 2021 at 17:10):
Thanks @Lloyd McKenzie - I'll submit the change request as a Jira in BR&R.
Gustav Vella (Sep 02 2021 at 18:29):
For posterity, here is the link to the jira https://jira.hl7.org/browse/FHIR-33147 - sadly still no feedback.
@Lloyd McKenzie in personal discussion, someone floated the idea of splitting the encounter I.E. introducing a study-related sub encounter to distingush between study-related Service Requests and all others.
While it appears to be a neat short cut, I think it propagates the present state of anarchy because AFAIK there is no standard pattern for (semantically) structuring encounters and sub encounters.
Hence I think that change request in the Jira is still valid. Or do you have any feedback or alternative thoughts since?
Lloyd McKenzie (Sep 02 2021 at 18:33):
This was raised less than a month ago. It takes most work groups a few months to get to new issues. (Sometimes much longer.) So I wouldn't give up on it. If you want to push for faster resolution, you can engage with the work group co-chairs and/or attend some of their calls and see if the request can be expedited.
Gustav Vella (Sep 02 2021 at 18:52):
Too bad it's in OO, which I don't attend. I'll hang on a while till we have to make a final call on this.
Thanks.
Geoff Low (Sep 13 2021 at 10:35):
We've been looking at this in principle as part of the SoA work. Our approach is a little less direct (and not complete as yet). We are linking a study design PD to the ResearchStudy via the protocol attribute and then assigning the study related actions as PD/AD for each planned event. We intend to use the AD to generate the ServiceRequest/Task resources and then track them that way. I'm not sure about needing a research study attribute on service requests where the information should be able to be inferred.
Gustav Vella (Sep 13 2021 at 16:06):
Hi @Geoff Low thanks. Can you explain what you are referring to by PD / AD? Am not acquainted with those acronyms.
Geoff Low (Sep 13 2021 at 16:35):
Sure, PlanDefinition and ActivityDefinition (apologies)
Gustav Vella (Sep 13 2021 at 18:06):
OK - I've been there (in thought) too. That's theory lessons for an Ideal world. The downside is that it requires a big bang for the whole shebang. Try to look at this from the point of view of a hospital team, their knowledge and the infrastructure available there - both EMR-wise and in terms of FHIR-capability. Also, name me a sponsor, who today or in the next few months will supply sites with a Protocol as PlanDefinition. You're putting the bar to high to getting anyone bootstrapped with relating any FHIR Data in the EMR with a ResearchStudy in an approachable way today or in the forseeable future.
Gustav Vella (Sep 13 2021 at 18:08):
That said, I’ll run this through. I could generate the PD/AD. The challenge will be reducing that structure for it to be consumed by the proprietary and limited means available in the EMR or relevant hospital systems.
@Geoff Low Do you have a reference PD/AD for a Protocol to try this out?
Lloyd McKenzie (Sep 13 2021 at 18:32):
Keep in mind that a PlanDefinition could be almost entirely narrative. How well coded/computable the protocol is is quite flexible. Agree that there aren't a whole lot of sponsors expressing computable protocols at the moment, but insofar as they're sharing protocol at all, PlanDefinition is the mechanism to do that in FHIR. Over time, the degree of computable precision can grow based on the level of sophistication the industry feels is worthwhile. (And the good news is that there's a great deal of work happening in terms of "fully" computable protocols in the clinical decision support space, so there's a different portion of the industry that's forging the trail and building tools that the research community can leverage if/when they're ready.)
Geoff Low (Sep 13 2021 at 20:27):
we've been building out the following: https://phuse-org.github.io/fhir-schedule-of-activities-ig/index.html
Geoff Low (Sep 13 2021 at 20:34):
we have a set of three simplified examples on https://confluence.hl7.org/display/FHIR/2021-09+Vulcan+-+Schedule+of+Activities as bundles
Gustav Vella (Sep 13 2021 at 21:18):
@Lloyd McKenzie I agree. My point of view is getting this done with the mandatory systems we have today - with all their limitations. The bottleneck is the EMR or whatever sofware you have managing the Order Entry - there is no way around that system (for all sort of Orders including Lab Orders) unless you want to break hospital policies. In the 10 or so systems I deal with, I'd be lucky to be able to add a custom key-value pair as additional metadata to the order. As long as I can keep the added complexity which Geoff is proposing to be infornt or behind that bottleneck, and just have a small linking reference included in the HIS/CPOE, all is good. Going over Geoffs' suggestion again It looks doable despite the overhead.
Gustav Vella (Sep 13 2021 at 21:19):
@Geoff Low - thanks for those references.
Geoff Low (Sep 14 2021 at 06:44):
No worries, we're meeting as part of the connectathon so if you wanted to come hangout that would be good. We're a little myopic on the topic of how data gets collected, as a really broad generalisation we have a series of boxes on a form with names that mean something to us, but there's little understanding of the workflow over and above done/not-done.
Last updated: Apr 12 2022 at 19:14 UTC