With CQL, the measure author is able to define functions to use in their measure. However, they do not just define the inputs and the outputs of the function, but in some cases define how to calculate the return from that input.

This is a problem when the functions use inefficient algorithms to find the desired output. Their functions will work fine in small test environments, however these quality measures are going to be run across millions of patients and the performance cost of ANY defined function ought to be optimized to be the best it can be.

Here is a perfect example of a sloppy function (from CMS-53):

*Arrival Time(Encounter "Encounter, Performed")
First(Encounter.facilityLocations Location
return start of Location.locationPeriod
sort ascending
)*

Anyone with basic understanding of algorithms can see that this is extremely inefficient. The function's goal is only to return the minimum value in a list of DateTimes. In order to do this, you only need one pass through the list to identify the minimum value. You do not need to sort the list. This function should be able to execute on O(N) efficiency, however the requirement to sort the list makes the maximum efficiency O(N*ln(N)) (assuming that the sorting is optimized).

Here is the same function reprogrammed in pseudo*CQL for O(N) efficiency:

*Arrival Time(Encounter "Encounter, Performed")
List=(Encounter.facilityLocations Location
return start of Location.locationPeriod)
Y= First(List)
ForEach(X in List, if X<Y then Y=X)
Return Y
)*