The included example of parameters is confusing:

Some options are represented as a parameter named "option" with the value representing the option name:
 

{
  "name": "option",
  "valueString": "EnableAnnotations"
}

Some options are represented as a parameter for which the parameter name matches the option name and the value is a boolean:

{
  "name": "enableCqlOnly"
  "valueBoolean": true
}

Some are represented in the table in section 2.17:

{
  "name": "signatureLevel",
  "valueString": "Overloads"
}

While others are not represented in preceding documentation at all:

{
  "name": "collapseDataRequirements",
  "valueBoolean": true
}

For boolean options, no guidance is given whether it should be represented as a parameter named "option" (like "EnableAnnotations") or a parameter named after the option (like "enableCqlOnly"). We only know by example.

This complexity is difficult for implementers and is also difficult to specify via a profile (as I've suggested in FHIR-43908). Is this complexity necessary? Could the Parameters.parameter.name just always be the option name and the value could be a string or boolean as appropriate? This would be easier to understand and easier to represent via a profile.