Stream: cql
Topic: Customer Overrides for ValueSets
Corey Sanders (Jan 26 2021 at 14:59):
We have a multi-tenant system that is executing CQL queries. In our existing system, it is common for clients to want to start with a standards-based value set and then modify it to fit their data needs. Codes are added or removed from the ValueSet. All of the rest of the CQL logic is the same between customers. We would like to be able to treat the ValueSet ID and/or version as parameters, but that doesn't work right now. The CQL language spec requires ValueSet ID and version to be only a string. Using cql_engine, I can plug in my own terminology provider that manipulates the response to terminology queries based on execution context, but I was hoping to not have to do that. Am I missing anything? Has this requirement been previously discussed?
Bryn Rhodes (Jan 26 2021 at 17:37):
This pattern has been discussed, but isn't landed yet. That approach (overriding in the terminology service layer) has been done before, but the machinery for that hasn't been exposed in the standard (or the implementation).
Bryn Rhodes (Jan 26 2021 at 17:38):
We've seen the "concepts library" pattern in multiple projects and are moving towards that as an approach.
Bryn Rhodes (Jan 26 2021 at 17:39):
The challenge is that it requires "runtime binding" of the versions. We are looking at using an "Asset Collection" library to support defining the concepts used, but that needs to be pulled in to the translator and engine in order to really work properly.
Bryn Rhodes (Jan 26 2021 at 17:40):
Basically, you define a "Concepts" library that has all the value set definitions, and you include that library, without specifying a version. In authoring environments, it binds to the authoring version. But in runtime environments, you could provide a version of that concepts library that references the local value sets.
Eric Whitley (Jan 26 2021 at 18:01):
@Corey Sanders
I'm really curious to know how you're approaching this from a governance perspective.
We've been asked about the same thing, but our response has been that changing a value set constitutes a new measure as it is a change to an artifact that drives the logic. We've portrayed the logic+value sets as a contiguous bundle of information.
Are you somehow planning on annotating that the CQL logic and value set references (changed at runtime) constitute a new version/derivative of the prior measure?
Corey Sanders (Jan 26 2021 at 18:17):
@Eric Whitley the answer that we would like in the spec is for parameter data that is used in the calculation of a measure to be echoed back to the user in the MeasureReport. We have other places in our logic, such as patient age ranges, where clients can request minor changes to standard rules using parameters and we want a way to be able to see those values as well. Right now, that doesn't exist and we have our own custom extensions to handle it in an internal IG.
Bryn Rhodes (Jan 26 2021 at 18:30):
So a capture of the parameters that were used to do the evaluation?
Corey Sanders (Jan 26 2021 at 18:32):
@Bryn Rhodes yes, and if ValueSet overrides were just input parameters to the CQL it would flow naturally into the same reporting mechanism.
Bryn Rhodes (Jan 26 2021 at 18:35):
That's interesting. We did, in CQL 1.5, introduce types for ValueSet, CodeSystem, and Code so that you could actually pass ValueSets by reference, so that would be a possibility. The challenge is that is at odds with the goal of static analysis of terminology dependencies. Especially as it relates to data requirements analysis, which is one of the primary design goals of CQL.
Bryn Rhodes (Jan 26 2021 at 18:37):
In quality measurement, we are currently working out the use of an asset collection library to specify value set versions, sort of a manifest that specifies versions for each dependency in a particular "release". We're thinking we could generalize that notion to library dependencies as well, and that would allow local implementations to specify their particular version of a library (the concepts library in particular). The manifest to use could then be a parameter to the evaluation.
Corey Sanders (Jan 26 2021 at 18:57):
Our primary use case right now is care gap identification to drive patient-provider engagement. We have internal measure authors that start with standards and customize to different client needs. With our legacy product, we see fairly regular maintenance of value set contents to match customer data. Measure logic changes less frequently, but does need to adapt to handle changing expectations such as when HEDIS added hospice exclusions. This is a dynamic process. I saw the data requirements stuff this past connectathon and was having a hard time connecting it to our use case. It felt like something that was done once a year or so, not something that happened dynamically during normal business operations. I admit that I need to dig deeper in that area though.
Robert McClure (Jan 28 2021 at 01:36):
@Corey Sanders What you need is what in V3 we called a Concept Domain which was essentially a named value set scope that requires run-time binding to the concepts needed, in this case a value set. I believe we have LOTS of reasons to try and bring this type of construct into FHIR.
Last updated: Apr 12 2022 at 19:14 UTC
