Stream: Da Vinci
Topic: CRD prefetch
Andy Gregorowicz (Aug 09 2018 at 17:57):
Just to make sure that I understand the approach to using prefetch. If we wanted to provide everything that the payer would need in the initial request, we would have the following prefetch query (white space used for readability):
ServiceRequest?id={{context.orders.ServiceRequest.id}}&_include=ServiceRequest:insurance
&_include:recurse=Coverage:payor
&_include=ServiceRequest:performer:PractitionerRole
&_include:recurse=PractitionerRole:practitioner
&_include:recurse=PractitionerRole:location
In this case, we would be including information about the payer by ServiceRequest.insurance -> Coverage.payor -> Organization. We would use PractitionerRole to record the provider requested to perform the service as well as the location for the service to be performed at.
Is this the expected approach?
Lloyd McKenzie (Aug 09 2018 at 18:26):
Yes, that's probably the route we'll go. It reduces the redundancy and keeps the number of variables passed back to a minimum
Andy Gregorowicz (Aug 09 2018 at 18:28):
OK. The only downside that I'm not sure we can get around is that the ServiceRequest will also be returned in the prefetch. It will be a duplicate of what is in context.orders. I don't know of a way to get around that using FHIR search. We may just have to live with it.
Lloyd McKenzie (Aug 09 2018 at 18:52):
Yeah. It's not optimal, but the alternative is a much more complex context variable approach. It's also a bit messy in that the same Coverages, Practitioners, etc. could be present in multiple variables - some in the MedicationRequest results, some in the ServiceRequest results, some in the DeviceRequest results, etc. However, it'll work and it requires the least imposition on the existing capabilities, so it's a reasonable starting point. After connectathon we can figure out whether more/different is needed.
Grahame Grieve (Aug 09 2018 at 19:01):
@Eric Haas I don't know what _config.yml is
Andy Gregorowicz (Aug 09 2018 at 19:40):
@Lloyd McKenzie Agree. We can go with what we have now. In the future, it seems like it would be nice if CDS Hooks had a way to let you in prefetch resolve a reference from a resource in the context. It's a further complication on the template syntax though (as you mention).
Lloyd McKenzie (Aug 09 2018 at 19:44):
Yes. The ideal would be able to point into references and amalgamate them across resource types even if the paths are different. That'd be a complex beast to describe though. And the CDS Hook fallback is "just write the queries you want and run them". The more complicated we make stuff, the more pushback there'll be.
Eric Haas (Aug 09 2018 at 20:20):
@Grahame Grieve the Jekyll config file : https://jekyllrb.com/docs/configuration/
Grahame Grieve (Aug 09 2018 at 21:04):
The IG publisher doesn't touch that
Eric Haas (Aug 09 2018 at 21:16):
@Grahame Grieve OK I thought maybe is overridden since it doesn't seem to do anything for me when like when I tried to use it for global parameters like baseurl
Lloyd McKenzie (Aug 09 2018 at 22:01):
It may just not be 'visible' to Jekyll. I'll try to play with it this weekend.
Last updated: Apr 12 2022 at 19:14 UTC
