FHIR Chat · Debug and coverage output · cql

Stream: cql

Topic: Debug and coverage output


view this post on Zulip Bryn Rhodes (Jul 08 2020 at 04:11):

J#27474 suggests that we consider defining debug and coverage output annotations for CQL. Debug output has been added to the Java reference implementation here: https://github.com/DBCG/cql_engine/tree/master/engine/src/main/java/org/opencds/cqf/cql/engine/debug, and I know that there is something similar in the JavaScript engine to support the coverage feature in Bonnie. Should we consider something along these lines as the starting point here? @Chris Moesel @Sam Sayer

view this post on Zulip Sam Sayer (Jul 08 2020 at 12:25):

@Bryn Rhodes can you share a sample of the coverage from the Java engine?

view this post on Zulip Chris Moesel (Jul 08 2020 at 12:30):

I didn't work closely with this part of the JS engine, but I think the general approach is that the JS engine stores values of each expression, using the expression's localId. When a run is completed, you know which expressions were executed and which ones weren't (because the ones that weren't don't have an entry in the localId map of results). Bonnie also wanted to keep track of the individual results which added some complication for queries since query logic loops on each item in the source. I don't remember exactly how that was resolved...

view this post on Zulip Bryn Rhodes (Jul 08 2020 at 22:28):

I don't have a serialization of the results yet, just the structures as defined at that link, but conceptually, it sounds like it's doing the same thing that Chris described, saving the value for each node that is visited (well, values, in the case that the node is visited multiple times).

view this post on Zulip Sam Sayer (Jul 09 2020 at 13:32):

I think the JS engine doesn't currently hold multiple values, it can only say whether or not the node was hit. I believe that was one of the improvements we wanted to make with the move to FHIR. @Chris Hossenlopp has the most JS engine experience so he can confirm/deny what I said.

view this post on Zulip Chris Hossenlopp (Jul 09 2020 at 13:44):

The JS engine results currently have the first "truthy" value or last "falsey" for each localId. "truthy" meaning non-empty list, not null, or true.


Last updated: Apr 12 2022 at 19:14 UTC