Currently, when users write SQL-definitions, there is no good way for them to reference metadata in their SQL in a metadatasharing and sync-safe way. Options currently are limited to complex joins against the global properties table (ugh), hard-coding ids like encounterTypeIds and conceptIds into their SQL (ugh), joining against concept_map (ugh), or by using Parameters of the right datatypes and forcing the users to specify these at runtime (ugh).
The option of these that is the closest to "right" is by using Parameters in the SQL Definition. This can work if the only main purpose of the definition is to be mapped into another definition (eg. a DataSetDefinition mapped into a ReportDefinition, as the values that are meant to be "fixed" can be done during the mapping process. However, this does not effectively allow the underlying definition to be run standalone in a way that keeps the "fixed" values fixed as they should be.
The proposed solution is to add an additional Set of Parameters onto all SQL-based Definitions, named "referenceData". These Parameters would be required to have a non-null defaultValue. They would be used in a pre-processing step to do replacement of values in the underlying SQL prior to evaluation.
This will allow users to refer to metadata in a sync and metadatasharing-compliant way. It will be strictly optional.