Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[Bundle/$apply-cql] with parameters [[]] #530
Comments
|
see attached for associated cqf-ruler logs |
|
Apologies for the delayed response. Would you mind running this without using the applyCql attribute? Let me know what you get. |
sure thing. just did that, and it looks like first of all, there are no errors! yay! on the other hand, no suggestions are coming back for any of our recommendations now (which are generated as a result of CQL execution). this is in line with my understanding of what "applyCql" does, which is to say, runs associated CQL and generates cards (i.e. "suggestions") as a response. (if my understanding of what "applyCql" does is wrong, please correct my understanding). so I'm like 99% sure we need "applyCql: true". has something changed between cqf-ruler 0.4.1 that would cause "applyCql: true" to suddenly not work? we've had that flag set since the beginning and it only just started breaking with the upgrade to 0.5.0. it seems that setting "applyCql: false" disables CQL execution. thoughts? thanks, and please let me know if there's anything else I can do to help. Matt |
|
see attached for cqf-ruler logs associated with applyCql=false execution (for which recommendations are evidently not executed as nothing comes back for them, which should be happening) |
|
The $apply-cql operation populates prefetch FHIR resource elements using CQL expressions. It was developed mainly to simplify CDS Hooks test cases where date and time elements needed to be maintained. |
|
Has anything changed on your end since the 0.5.0 release? Perhaps the prefetch data is formatted differently? |
nothing has changed in our codebase. the request that has worked against cqf-ruler 0.4.1 was not modified before attempting to get it to work against cqf-ruler 0.5.0. the upgrade to 0.5.0 has been something we've been putting off for a while because other things were changed in cqf-ruler (how it starts, where the FHIR endpoint is, etc.), so we were waiting until a good opportunity to make the jump. so we're in the process of making that jump, just trying to get the stuff that's been working to just run against the new version of the ruler, but yeah it looks like the 0.5.0 version of cqf-ruler doesn't know how to execute CQL anymore. it's very confusing. does the 0.5.0 release require a differently formatted prefetch than what was required to work against 0.4.1? |
|
but thinking about it, it's not like anything having to do with the prefetch should cause the error. the prefetch just determines what's available to the CQL at the time that it's loaded. but if something isn't in the prefetch, the ruler should just go out to the FHIR server to acquire what's missing. the whole workflow shouldn't blow up saying "hey we don't know how to handle $apply-cql anymore". that sounds like it's happening before any CQL execution occurs, doesn't it? |
hm, okay yeah we don't do anything with CQL to populate prefetch resources. we do include resources in the prefetch, but they're all provided statically by our app and embedded into the CDS Hook request. |
It doesn't.
If the prefetch is populated, the ruler will assume the caller has provided all the necessary/appropriate resources and will not make further requests.
You're correct that the error is coming back before any CQL execution occurs and that is definitely not ideal. It seems like in the 0.4.1 version of the ruler, the $apply-cql operation ran and just returned the same prefetch elements since there was no CQL to execute. That is why I asked if the way your prefetch data is formatted changed. Since it hasn't, I will need to run some tests on our end to make sure everything is running as expected. |
|
I ran some tests and everything seems to be running as expected. Therefore, I will need more information. Would you mind sharing the PlanDefinitions and Libraries used in this scenario? ([email protected]) |
cool, thanks for confirming that!
yeah, true - as I understand, this occurs on a Resource-by-Resource basis
hm, that may be the case. however, it seems to me that the $apply-cql operation isn't running at all in 0.5.0 when applyCql=true (when false, I'm guessing the ruler doesn't attempt to make the call in the first place). I'm looking at this line in R4EvaluationContext: ... so why the error "The FHIR endpoint on this server does not know how to handle POST operation[Bundle/$apply-cql] with parameters [[]]" ?
I have no idea if the questions above apply, I am not familiar with the inner-workings of the ruler's architecture. this is just where my mind is at. thoughts? I appreciate your help figuring this out! Matt |
|
To be clear, just because the service is returning an empty array of cards doesn't mean the CQL expressions specified in the PlanDefinition haven't been executed. It could be that the conditions specified in the PlanDefinition haven't been met, which could be due to several different reasons (e.g. the patient data doesn't meet the trigger conditions, the CQL isn't being evaluated correctly, terminology issues, etc...). I would like to determine why the condition isn't triggering. If it is alright with you, I'd like to move away from discussing the $apply-cql operation since it isn't relevant in this scenario. There may be problems with it in v0.5.0 and I will look into that. |
that is true, in theory. the patients I'm using as test data are designed to elicit particular responses from the executed recommendation workflows. I've tested with several different patients, all of which should generate something, but none generate anything. so I don't think it's a data issue. I'm currently trying to get cqf-ruler 0.4.1 running on my system again (my workstation was reimaged a couple weeks ago) to verify precisely what should be coming back for these patients as a response, but I've been running into these annoying Maven errors about "zip END header not found" on a bunch of cqf-ruler's dependencies, I think it could have to do with the Java version I've been using (Java 17 / OpenJ9). I'm downgrading to Java 11 / OpenJ9 to see if it makes a difference.
yes thank you, if you're certain the $apply-cql issue is a red herring, I'm happy to move away from it. please keep investigating. if you would like the associated Libraries, PlanDefinitions, and ValueSets, please let me know and we can figure out getting those to you. |
|
If you're sure that the test cases are valid and they work in v0.4.1 and aren't working in v0.5.0, then I think I will need to debug the scenarios on my end to determine the issue. |
|
yeah I'm sure that of the three test cases I tested against 0.5.0, for none of them to return anything is extremely extremely suspicious. I wish I could get 0.4.1 to build to generate expected results for you, this "zip END header not found" error during "mvn package" is troublesome. been spending all afternoon debugging this. (grumble) anyhow. please see attached for associated vocabulary and resources that get loaded into the ruler and which are involved in the execution of these recommendations, and let me know if there's anything else I can do in the meantime. |
|
Regarding the Monitoring scenario: Based on the prefetch data from the cqf-ruler-localhost-applycql.false-20220621.txt file posted above, the patient doesn't meet the inclusion criteria because there isn't a Condition indicating pre-existing hypertension. I don't see any Condition resources in the prefetch data. |
|
okay, I got cqf-ruler 1.4.1 working again. see the cqf-ruler log file below for an example of it working as expected: from these logs, we can see that the following is passed as a request for the Monitoring recommendation:
and which generates the following expected response:
(other cards were generated from other recommendations, but I'm not including those for the sake of brevity, and we only need one solid working example as a proof of concept, which the above illustrates nicely) note that while "applyCql:true" in the above request, I can confirm that in subsequent tests that "applyCql:false" still DOES work and generate cards as expected (so my earlier understanding of what applyCql does is corrected). loading the same exact patient record into the app, but running against cqf-ruler 0.5.0 instead, the following logs are generated: from these, we can see that the following request is passed as a request for the Monitoring recommendation:
and which generates the following response:
(this should generate a card with summary "Patient did not have a preexisting hypertensive condition" as above in the 1.4.1 example, but as you can see, there is nothing here) hope this helps! please let me know if I can be of any other assistance in sorting this out. thanks! |
|
Thanks Matt. I am investigating the issue. |
|
I have tracked down that the following expression is returning null instead of false: Causing this expression to also return null: I am now looking into why the "Meets Exclusion Criteria" expression is returning null |
|
Success! I have generated the desired response from v0.5.0. The issue is that the Patient resource needs to be included in the prefetch resources. |
great! glad to hear it. it's interesting you mention including the Patient resource in the prefetch, I thought we had been doing that, and in fact we were, but I commented out that block of code referencing "nested extensions that CQF Ruler can't handle via prefetch" - I honestly don't recall precisely what these nested extensions were that prompted me to disable this, but I do recall that we did so knowing that cqf-ruler would obtain the Patient resource directly from the FHIR server if it's missing from the prefetch, and it's worked fine without it in the prefetch to date, soo ... do you know why, specifically, 0.5.0 requires the Patient resource to be in the prefetch? in any case, thanks! I'm going to test this out and see if it works, will keep you posted |
|
We changed behavior from v0.4.1 where it would attempt to resolve a partially completed prefetch. That had a lot of drawbacks regarding how that would be determined and performance. So v0.5.0 was updated to assume that if a prefetch was populated it was complete and no requests for resources would be made. Unfortunately, we didn't capture that change in behavior in any of our documentation. We will be updating any relevant documentation to make that behavior clear. |
|
ah, yes that is very useful and important information, thanks for clarifying that modified functionality! so, to be clear, if there exists even a single resource referenced in the prefetch, cqf-ruler will make no calls to the FHIR server, full stop? as such, to be clear, if ANY resources are populated into the prefetch, ALL resources must be represented there. correct? is there any way to modify this behavior? it will be troublesome for our app to need to maintain synchronized, detailed knowledge of the resources that the recommendations it references require, and in fact, to need to acquire those resources separately only to pass them into the ruler's prefetch. the app shouldn't need to care about or be bothered with those details. poor encapsulation of concerns and whatnot. I tested the app against 0.5.0 including the Patient resource in the prefetch, which worked. so yay, it sounds like this issue is resolved. thank you for helping to track this down! |
Correct. If the prefetch is populated the cqf-ruler will assume that it is complete.
We are aware that behavior is not ideal and are working toward a better solution.
A possible temporary solution for v0.5.0 might be to not include prefetch resources at all and allow the service to handle prefetch data retrieval. Obviously that will hurt performance, but it does ease the load on the app. We should have this issue resolved in the next release at which point your app can revert to sending partial prefetched data.
That's great! I am glad we got this figured out. |
cool, I look forward to that better solution.
negative, this cannot work. our app crafts FHIR resources on the fly that include self-recorded BP measurements, records of having received counseling, experienced adverse events, etc., none of which exist in the source FHIR server. the only solution is to have our app be intimately aware of all the FHIR resources the recommendations require and to act as a middleman to shuttle those resources from the FHIR server to the ruler via prefetch. perhaps the solution is to just stay on 0.4.1 until the ruler improves. that would be unfortunate but it may be what we need to do :( |
|
That is unfortunate. We will prioritize getting that functionality implemented. I will create a new issue to capture that (#536). Closing this. |
cool, thank you very much! yes, this issue presents a significant metaphorical monkey-wrench into our development process and timelines. we're evaluating options but frankly none of them are good. we sincerely appreciate your attention to resolving this matter! |
working in cqf-ruler master branch updated this morning. "mvnw package" builds everything successfully. running CQF-ruler starts great. loading resources into the ruler goes fine.
however, attempting to execute a PlanDefinition via CDS-hooks call (with attribute "applyCql: true"), CQL execution fails with the following error:
2022-06-07 09:18:39.157 [http-nio-8080-exec-4] ERROR o.o.c.r.cdshooks.r4.CdsHooksServlet [CdsHooksServlet.java:238] ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: HTTP 400 : Invalid request: The FHIR endpoint on this server does not know how to handle POST operation[Bundle/$apply-cql] with parameters [[]]It's not clear why this is happening. Everything worked fine in CQF-ruler 0.4.1. I've reached out to the Zulip chat channels but so far no responses.
The text was updated successfully, but these errors were encountered: