The cqf-cqlOptions extension represents CQL translator options via a Parameters resource. This Parameters resource, however, has no constraints – so there is no formal/computable guidance regarding what parameter names to use.

Section 2.17, Translation to ELM, however, lists the common set of options: EnableAnnotations, EnableLocators, DisableListDemotion, DisableListPromotion, DisableMethodInvocation, EnableDateRangeOptimization, EnableResultTypes, EnableDetailedErrors, DisableListTraversal, SignatureLevel. The provided example lists additional options as well. Sometimes options are represented as a parameter named "option" and a "valueString" containing the option, but other times the parameter name corresponds to the option name and the value is a boolean or string.

This is sufficiently complicated such that it would be helpful to implementers if these options were formally specified via a CQLOptions profile on Parameters. The parameters array might need to be sliced since different parameters have different requirements, e.g.:

• Slice for parameter w/ name "option" would constrain value[x] to string and bind (extensible) to a value set with common option names
• Slice for parameter w/ name "format" would constrain value[x] to string and bind (required) to value set w/ XML and JSON.
• etc.

Alternately, if you simplified the approach such that every option was always reflected in the parameter name (instead of a parameter called "option"), then the profile would be much simpler (more like the ModelInfoSettings profile I proposed in FHIR-43901).