CriterionTaxonomy, adding "Criterion.selection.other"

[JachymHercher]

For the purposes of reusing the CriterionTaxonomy in the eForms and the Ontology, we would like to request adding a code "Criterion.selection.other" (currently, there is only "criterion.other").

This code would be used for marking other criteria than "Suitability to pursue the professional activity", "Economic and financial standing" and "Technical and professional ability". Such criteria may exist at least under the sectoral and defence directives.

[ec-mcs]

We could use "Criterion.selection.other" for defence where we have some selection criteria on security.

[mireiaBM]

This issue will be addressed in version 3.0.0 of the ESPD data model.

[mireiaBM]

After a meeting with the MS held on September 10, 2019, it was decided that there will be a new criteria in the Procurement Documents named “SUPPLEMENTARY.SELECTION.CRITERIA”. This new criteria must be checked from a legal perspective with DG GROW and will be implemented in version 2.1.1.

[JachymHercher]

Can you explain why, please? What is the difference compared to criteria.selection.other?

[ec-mcs]

I personally don't really care about the naming. To have consistency, I would vote for criteria.selection.other. The only problem that I see is that MS should not add for procedures above EU thresholds their own selection criteria because in principle they are (or should be) covered by the directive. Having that said, and as mentioned above, for the defence procurement we need to add 2 criteria on security. This category I would call probably criteria.selection.security.

[JachymHercher]

@ec-mcs, "MS should not add for procedures above EU thresholds their own selection criteria" is true for Directive 2014/24/EU, but in case of Directives 2014/25/EU and 2009/81/EC there can also be "other" criteria. (This option is largely theoretical, but the directives leave the option open.) eForms' codelists currently prescribe using "CRITERION.OTHER" to cover these cases.

[JosePRevenga]

What if we created selection criteria of the style CRITERION.DEFENCE.SELECTION.OTHER? this way we'd avoid that selection criteria currently defined in the ESPD criteria taxonomy could not be replaced by mistake (or laziness) by a CRITERION.SELECTION.OTHER. If Directive 25 needs this too we could come up with something like CRITERION.UTILITIES.SELECTION.OTHER.

[JachymHercher]

I agree with the need to ensure data quality, but shouldn't this rather be done via business rules? In particular, shouldn't there be a rule saying that CRITERION.SELECTION.OTHER cannot be used under D24?

[JosePRevenga]

Thank you for your input, it's a great idea. Unfortunately as far as I know, the ESPD does not capture the legal basis of the procedure. Maybe these datum could be added to future versions of the ESPD, @ec-mcs ?

[JachymHercher]

Doesn't the ESPD have the TED notice/procedure identifier? If yes, then the legal basis should be retrievable via the TED APIs.

[JosePRevenga]

Unfortunately, our scope is limited to the ESPD-EDM model. We cannot build Schematron rules that check data outside of ESPD documents, e.g. what happens in TED is totally unknown by the ESPD models and rules. The opposite could be implemented, but still the code lists are part of ESPD-EDM model: the broader the concept is, as in CRITERION.OTHER, the largest the inconsistency introduced.

A system that is able to operate both with the ESPD instance and the TED API, can instead cross-check the legal basis identifier (e.g. Directive 24) against a narrower code like CRITERION.DEFENCE.SELECTION.OTHER does easily identifying the inconsistency and triggering a validation exception.

In conclusion, we stick to our proposal of adding these two new criteria: CRITERION.DEFENCE.SELECTION.OTHER and CRITERION.UTILITIES.SELECTION.OTHER.

[JosePRevenga]

As announced in my previous comment, new Criteria DEFENCE-SELECTION-OTHER and UTILITIES-SELECTION-OTHER have been introduced in v2.1.1 for the specific needs of procedures regulated by Directives 2009/81/EC and 2004/17/EC, respectively.