CQL 1 1 DSTU Update
Return to Clinical Decision Support Work Group
The CDS Work Group has received numerous comments on the CQL DSTU specification. These comments have been discussed and resolutions approved, and the changes applied to an updated version of the specification, CQL Release 1.1.
The CDS Work Group applied HL7 Guidance to determine the appropriate review process and selected the peer review DSTU Update Process. The review period begins April 18th, 2016, and will be two weeks, closing Monday, May 2nd. Any review comments received during that time will be discussed at an upcoming CDS WG call.
The ballot review package is available here (members only):
For an overview of the changes, please see this presentation:
Comments can be submitted either by updating this page and adding a comment to the table below, or by submitting a DSTU comment here.
|Number||Name||Item||Existing Wording||Proposed Wording||Comment||Disposition||Disposition Comment||Mover/Seconder||For||Against||Abstain||Responsible Person||Change Applied|
|1||Chris Moesel||3.1.7 Operator Precedence||= <> ~ !~||= != ~ !~||If we are introducing !~ as not equivalent, then I think it makes sense to have != be not equal, rather than <>. This is consistent with many programming languages.||Persuasive||The <> operator will be changed to != and references throughout the specification and tooling will be updated to reflect the change||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|2||Chris Moesel||3.2.3 Function Resolution||Note that although CQL supports forward declaration for expressions, the same is not true for function definitions. Forward declaration for function definitions is not currently supported by CQL.||This limitation seems arbitrary and makes CQL more difficult to author. Why don't we support forward declaration of functions?||Persuasive||The specification will be updated to enable forward declaration for functions. The CQL-to-ELM translator will also be updated to support this.||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|3||Chris Moesel||126.96.36.199 Implicit Conversions||The second page of the table is difficult to read because the table headers are lost. We should repeat the table headers when tables get split across pages, or push the whole table to the second page.||Persuasive||Headers will be duplicated when a table is split across pages||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|4||Chris Moesel||188.8.131.52 Implicit Conversions||The conversion from a tuple to a structured type requires that the set of elements in the tuple type be a subset (possibly proper) of the elements in the structured type.||The conversion from a tuple to a structured type requires that the set of elements in the tuple type be the same set or a subset of the elements in the structured type.||I think I know where you're trying to go with the (possibly proper) parenthetical, but I find it confusing. I think the suggested wording makes it clearer.||Persuasive||Proposed wording will be adopted||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|5||Chris Moesel||4.11 Structured Values||Indexers specified in paths must be literal integer or string values.||Indexers specified in paths must be literal integer values.||The specification only indicates integers as proper indexers -- I'm not sure how/where you would use a string indexer.||Persuasive||Proposed wording will be adopted||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|6||Chris Moesel||9.6.12 Multiply||For multiplication operations involving quantities, the input quantities must be of the same dimension (not necessarily the same units), and the resulting quantity will have the appropriate unit.||Should multiplication require the same dimension? Doesn't 3 'cm' * 12 'cm2' == 36 'cm3'? Or is that just too potentially complex?||Persausive||This is the intended meaning of the wording "dimension (not necessarily the same units)". Perhaps "For multiplication operations involving quantities, the resulting quantity will have the appropriate unit. For example, 3 'cm' * 12 'cm2' evaluates to 36 'cm3'."||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|720||Bryn Rhodes||DSTU Comment #720||Current implementation of this change requires single codes to be expressed as defines within the library||We should support top-level constructs for concept and code, the same way we do for codesystem and valueset in the headers for the library||Add code and concept top-level elements within CQL and ELM to enable single code references to be described in the same way that codesystem and valueset are||Persuasive||Top-level constructs will be added to support the use of single codes and concepts within CQL||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|
|Floyd Eisenberg||General||The term "string literal" is confusing to non-technical users. Is there are more understandable way to express the concept?||Persuasive with mod||It's difficult to find a more precise term that captures the important distinction between a "literal" and "value" though. We will provide additional documentation to clarify the meaning, but it really is an important distinction that should be understood.||Bryn Rhodes/Richard Esmond||8||0||0||Bryn Rhodes||Y|