CQL Bug: Unhandled Exception in HypertensiveEmergency recommendation

[aeyates]

I noticed this when double checking recent recommendation changes in prod. This patient had no blood pressures.

Need to investigate what could cause this.

[aeyates]

In this particular case, the prefetch did not pass any observations at all since there were no Blood Pressures of interest. This makes CQL fall back on asking for observations:

GET https://epicmobile.ohsu.edu/FHIRPRD/api/FHIR/R4/Observation?subject=Patient%2FehvCN2ZQPHekqtOh64bxxc90dcNQEE90h-nouX-vqbbc3

It is likely that one or more of these observations are not formatted in a way the CQL expects. From the message, it appears they are missing both category and code? I'll have to do some experimentation to figure out what is missing and check for it.

[aeyates]

Ah, so the problem is Epic (again). It does not allow queries of observations by subject alone. You have to provide either a code or a category in the URL or the query fails. We had moved away from the more specific queries in CQL because we want absolutely everything to come in from the prefetch and we do not want to go out to the FHIR server to get anything. The only way to guarantee this is to put fake things in the prefetch like we do for adverse events. It seems like we need to do the same for observation and encounter if we're going to avoid this.

[aeyates]

I tested the patient "No Data" and confirmed that the following fake resources were added to the prefetch: Observation, Condition, Goal, Adverse Event, Procedure, MedicationRequest. There were no calls to the FHIR server in the CQF Ruler logs.

[aeyates]

This is still an issue in the Sandbox for patient Helena C DMICE. This patient has no Conditions in their prefetch, so CQF Ruler tries to query the FHIR server and receives an error because the query is not formatted to meet Epic's more restricted specification.

[aeyates]

Hey @mattStorer . Here's some fun for you. I was noticing no fake condition was being created in POC. This is because Epic's response when you ask for conditions (and probably other resources) is very different in terms of formatting. If I query the sandbox for conditions, here's what I get. Notice there is no "entry" array for the bundle, because there are no conditions:

{ "resourceType": "Bundle", "id": "025fcf62-4e1c-4730-aca4-ab6b1d0e042b", "meta": { "lastUpdated": "2023-12-01T00:27:54.397+00:00" }, "type": "searchset", "total": 0, "link": [ { "relation": "self", "url": "https://gw.interop.community/COACHsandbox/data/Condition?category=http%3A%2F%2Fterminology.hl7.org%2FCodeSystem%2Fcondition-category%7Cproblem-list-item&subject=Patient%2FH-RecommendMoreBPs" } ] }

Now, check this out. Here's a similar response in Epic. Here, it chooses to use the entry array to tell us there are no entries! Ugh. So we cannot rely on a count of the entries in a resource to tell us whether we have any or not. We could look at "total", but I don't think that field is guaranteed to exist in a response. FUN!

{ "resourceType": "Bundle", "type": "searchset", "total": 0, "link": [ { "relation": "self", "url": "https://epicmobile.ohsu.edu/FHIRDEV/api/FHIR/R4/Condition?subject=eJZNyNI76evAXniiuaXWgi-hQMJGR7gUqcDsAiCFXt4I3&category=problem-list-item&_format=json" } ], "entry": [ { "fullUrl": "urn:uuid:00000000-0128-c760-dfe5-450d47df394c", "resource": { "resourceType": "OperationOutcome", "issue": [ { "severity": "warning", "code": "processing", "details": { "coding": [ { "system": "urn:oid:1.2.840.114350.1.13.135.3.7.2.657369", "code": "4101", "display": "Resource request returns no results." } ], "text": "Resource request returns no results." } } ] }, "search": { "mode": "outcome" } } ] }

[aeyates]

I guess we could do a count of entries that have the resource type we are expecting. In Epic's case, the single entry is of type "OperationOutcome"

[aeyates]

Resolved in 1.4.2