anchor.diff:  
   Prop_Val = CUSTOM^fqt:yearFromDateTime
   
  +
  +.Special Scenario 8) To Translate a SIMPLE searchType into an IN searchType criterion.
  +Sometimes a single coded value needs to be translated into many coded values.
  +For example, a single Multum Drug Code translates into many NDC Drug Codes.
  +The entire criteria would need to be converted from a SIMPLE searchType into an IN searchType.
  +
  +Prop_Name = ATTR_VALUE_TRANS_FUNC
  +
  +Prop_Val Format = SIMPLE_TO_IN^fqt:customDataConversionFunction
  +
  +e.g. Prop_Val = SIMPLE_TO_IN^fqt:getNdc
  +
  +The Optional fqt:customDataConversionFunction name is used if the retrieved DTS data needs additional processing.
  +For example, we have retrieved full NDC descriptions from the DTS, but we only wanted the NDC Codes within the Full description.
  +Therefore, we can apply a custom XQuery function to strip out only the NDC Codes.
   
   
   
  
positive.code: 
  Note that duplicate Aliases are removed during the cleanup phase. So having more than one of these configured is ok. However, in order to support ‘AND’ conditions with multiple fields in the SAME table, we need to replace <criteria> with a subquery template using Special Scenario 4 above. 
  
  .Special Scenario 6) Add Extra Alias for Special Cases
  Sometimes we have an alias that translates to multiple aliases due to hierarchy relationship levels. This EXCLUDES Observation Types Issues. For example, FURTHER.orders table translates to OpenMRS.patient.orders table. Therefore, we need another alias to support the Sub Level. We need the Translated aliases to be like this, where the ord will go through the patient object:
  
  
negative.code: |java.util.UUID | xs:string
  |=======================
  
  .Normal Scenario 4) Configure property for the Composite ID Association.
  This is currently needed to support queries within previous Query Result Sets.
  
  Prop_Name = ATTR_VALUE_TRANS_TO_JAVA_DATA_TYPE
  