CQL v5

[antvaset]

• All non-null CQL values are represented as instances (implementors) of the sealed Value interface. Boolean, Integer, Long, Decimal, String, and List from the org.opencds.cqf.cql.engine.runtime package are used intead of kotlin.Boolean, kotlin.Int, kotlin.Long, BigDecimal, kotlin.String, and kotlin.collections.Iterable<T>.
• The evaluation visitor, all evaluators, engine API, FhirTypeConverter, and related tests are updated accordingly to use Value instead of Any.
• JUnit and Hamcrest are replaced with kotlin.test in the majority of tests along the way.
• The original Value object is renamed to Constants. The CqlList class is replaced with the SortHelper.compare() method.
• Non-system structured types (e.g. instances of FHIR.Patient, FHIR.string, etc.) are now represented in the engine as ClassInstances. A ClassInstance is a structured value (like a Tuple) with a QName type tag like {http://hl7.org/fhir}Patient. As a result:
  • the engine only operates on a fixed set of Kotlin types, and HAPI FHIR structures and other custom types do not bleed into the runtime,
  • resolvePath(), as(), setValue(), objectEqual(), objectEquivalent(), resolveType() are no longer needed in the ModelResolver interface.
• Java Class<T> references are replaced with type specifiers and type QNames (both multiplatform) in the engine. As a result:
  • packageName(s) is no longer needed in ModelResolver and is(value: Any?, type: Class<*>?): Boolean? changed to is(valueType: String, type: QName): Boolean?,
  • type testing is improved so e.g. Interval[1,2] is Interval<Integer> returns true and Interval[1,2] is Interval<Time> returns false,
  • function resolution is more robust when function refs are compiled without signatures.
• In FhirModelResolver : ModelResolver, the is(valueType: String, type: QName): Boolean? method now returns true only if {http://hl7.org/fhir}_valueType_ extends type or is the same as type. As a result, expressions like FHIR.integer { ... } is FHIR.positiveInt and FHIR.Quantity { ... } is FHIR.Age return false because FHIR.integer is a supertype of FHIR.positiveInt and FHIR.Quantity is a supertype of FHIR.Age.
• Fix DescendentsEvaluator.

[github-actions]

Related Issues

The following open issues may be related to this PR:

Issue	Title	Score	Matched Terms
#1133	ToList is not implemented according to the spec	57.5	"com cqframework", "cql engine", "org fhir", "cqframework clinical", "opencds cqf", "org opencds", "hl7 org", "cqf cql", "https github", "github com", "quality language", "clinical quality", language, github, returns, quality, com, types, because, null, expressions, https, clinical, list, type (path), cqframework (path), java (path), src (path), opencds (path), engine (path), code (path), retrieve (path), fhir (path), main (path), org (path), cql (path), cqf (path), elm (path), execution (path), hl7 (path), set (path), value (path), test (path)
#1505	'Collapse' on at least 2 closed datetime intervals without a high value always fails	55.5	"com cqframework", "cql engine", "engine runtime", "cqframework clinical", "opencds cqf", "org opencds", "cqf cql", "https github", "github com", "quality language", "clinical quality", runtime, language, github, quality, com, interval, because, null, https, bigdecimal, clinical, without, list, true (path), cqframework (path), quantity (path), java (path), before (path), src (path), evaluator (path), opencds (path), engine (path), executing (path), sort (path), collapse (path), main (path), org (path), cql (path), cqf (path), elm (path), date (path), value (path)
#1430	Correctly support CQL to FHIR (and vice versa) type mapping	53	"com cqframework", "cql engine", "cqframework clinical", "opencds cqf", "org opencds", "cqf cql", "https github", "github com", "quality language", "clinical quality", fhirtypeconverter, language, instead, github, quality, com, represented, time, types, https, use, clinical, resources (path), type (path), cqframework (path), java (path), support (path), src (path), opencds (path), engine (path), code (path), context (path), fhir (path), converter (path), library (path), main (path), org (path), cql (path), cqf (path), evaluation (path), resource (path), hl7 (path), data (path), set (path)
#1486	Allow a custom implementation of the State Cache	51.5	"com cqframework", "cql engine", "cqframework clinical", "opencds cqf", "org opencds", "cqf cql", "https github", "github com", "quality language", "clinical quality", language, github, custom, quality, long, com, expressions, object, https, interface, needed, use, clinical, class, list, cqframework (path), java (path), support (path), src (path), opencds (path), engine (path), library (path), main (path), org (path), cql (path), cqf (path), execution (path), boolean (path)
#1287	Revisit CQL Engine and Result APIs	49	"com cqframework", "cql engine", "cqframework clinical", "opencds cqf", "org opencds", "cqf cql", "https github", "github com", "engine result", "quality language", "clinical quality", language, github, along, quality, com, api, https, clinical, class, result (path), cqframework (path), java (path), src (path), opencds (path), engine (path), function (path), code (path), retrieve (path), main (path), org (path), cql (path), cqf (path), execution (path)

Tip: If this PR addresses any of these issues, please link them using Closes #NNN or Refs #NNN in the PR description.

[github-actions]

Formatting check succeeded!

[codecov]

Codecov Report

❌ Patch coverage is 73.09942% with 46 lines in your changes missing coverage. Please review.
✅ Project coverage is 62.82%. Comparing base (9c04406) to head (8087d7f).

Files with missing lines	Patch %	Lines
...cql/engine/fhir/converter/BaseFhirTypeConverter.kt	43.75%	1 Missing and 17 partials ⚠️
...cds/cqf/cql/engine/fhir/model/FhirModelResolver.kt	78.48%	6 Missing and 11 partials ⚠️
...f/cql/engine/fhir/converter/R4FhirTypeConverter.kt	83.33%	0 Missing and 2 partials ⚠️
...ql/engine/fhir/retrieve/Dstu3FhirQueryGenerator.kt	33.33%	2 Missing ⚠️
...f/cql/engine/fhir/retrieve/R4FhirQueryGenerator.kt	33.33%	2 Missing ⚠️
...ql/engine/fhir/converter/Dstu2FhirTypeConverter.kt	91.66%	0 Missing and 1 partial ⚠️
...ql/engine/fhir/converter/Dstu3FhirTypeConverter.kt	91.66%	0 Missing and 1 partial ⚠️
...f/cql/engine/fhir/converter/R5FhirTypeConverter.kt	92.30%	0 Missing and 1 partial ⚠️
...cql/engine/fhir/retrieve/BaseFhirQueryGenerator.kt	50.00%	0 Missing and 1 partial ⚠️
...e/fhir/retrieve/SearchParamFhirRetrieveProvider.kt	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1713      +/-   ##
============================================
+ Coverage     62.18%   62.82%   +0.64%     
+ Complexity     3900     3833      -67     
============================================
  Files           210      210              
  Lines         20302    19861     -441     
  Branches       3860     3767      -93     
============================================
- Hits          12624    12477     -147     
+ Misses         6074     5806     -268     
+ Partials       1604     1578      -26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Zylox]

We are currently using a custom modelinfo and a custom modelresolver to implement cql over internal data types that are not fhir related. This is well supported currently. These changes to modelresolver seem to make that impossible now. Is this engine only going to support FHIR, specifically hapi fhir, or is there some other avenue to get existing behavior that i am missing.

Fully extracting every record into a CqlClassInstance would be prohibitively poorly performing for us. Right now, the fact that we can retrieve objects at request time with resolvePath is very useful.

If CqlClassInstance were an interface that allowed similar behavior we could make this work, maybe. You could even then implement the interface by something identical to the current implementation if for some reason that is performant for you, where cqlClassInstanceImpl.resolvePath("value") performs a get on elements, and others like my team can back it with our existing data structures. This approach still wouldnt be ideal as we would have to wrap every object in an adapter, but its preferable to having to fork off the engine.

[antvaset]

Hi @Zylox,

These changes to modelresolver seem to make that impossible now. Is this engine only going to support FHIR, specifically hapi fhir, or is there some other avenue to get existing behavior that i am missing.

The engine still supports any CQL model (models are made of types described in the spec). I've documented all supported types in Src/java/engine/cql-value-types.md and how they are represented in the engine. CqlClassInstance is a container for named structured types (also referred to as class types or typed tuples), and they aren't FHIR-specific or HAPI FHIR-specific.

Fully extracting every record into a CqlClassInstance would be prohibitively poorly performing for us. Right now, the fact that we can retrieve objects at request time with resolvePath is very useful.

If CqlClassInstance were an interface that allowed similar behavior we could make this work, maybe. You could even then implement the interface by something identical to the current implementation if for some reason that is performant for you, where cqlClassInstanceImpl.resolvePath("value") performs a get on elements, and others like my team can back it with our existing data structures. This approach still wouldnt be ideal as we would have to wrap every object in an adapter, but its preferable to having to fork off the engine.

The elements of CqlClassInstance can be anything that implements MutableMap<String, Any?>, so you could instantiate CqlClassInstance with something like myLazyMap that only extracts the underlying records upon request. It would therefore materialize incrementally, as needed by the engine during evaluation, e.g. load the value of a specific element when the Property operator is applied or enumerate all elements when Descendants is applied.

[sonarqubecloud]

Quality Gate failed

Failed conditions
20.1% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[antvaset]

The source branch engine-structured-types has been renamed to v5 and this PR was automatically closed. #1755 is the new pull request.