ehn-dcc-development / eu-dcc-schema

Schema for the ehn DCC payload
Apache License 2.0
164 stars 59 forks source link

"nm" field in test entry #56

Closed lcimaglia closed 3 years ago

lcimaglia commented 3 years ago

Hi

as for the test entry I see the following fields:

    "nm": {
      "description": "NAA Test Name",
      "type": "string"
    },
    "ma": {
      "description": "RAT Test name and manufacturer",
      "$ref": "#/$defs/test-manf"
    }

The Annex reports this fields as following:

(e) test name (optional for NAAT test); (f) test manufacturer (optional for NAAT test);

From my understanding, the NAA Test are always considered valid for generating a DGC. So is the "nm" field really necessary?

gabywh commented 3 years ago

Hi, not sure if I understand your question, so let me summarize the position with respect to NAAT and see if that helps / answers your question. If not, please feel to clarify.

Correct that test name, test manufacturer are optional for NAAT test, as per Annex in https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52021PC0130

So for NAAT, you are not required to provide them.

In DGC.Types.schema.json we have:

    "test_entry": {
      "description": "Test Entry",
      "required": [
        "tg",
        "tt",
        "sc",
        "tr",
        "tc",
        "co",
        "is",
        "ci"
      ],

Where [nm, ma] are not required st JSON schema level, precisely for this reason.

Conversely, they are required for non-NAAT.

These kinds of things are difficult to model in a JSON schema (although I guess never impossible...). This is where the processing stage for business rules comes in very useful, since "test name / test manf not required for NAAT" is essentially a business rule for generation / issuance as well as for verification. These kinds of rules can be easily incorporated into code in the business rules processing stage see e.g. https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ#what-do-the-typical-processing-stages-look-like-for

lcimaglia commented 3 years ago

Hi

I will try to clarify a bit on my question. The "nm" field is not associated with a value set in the current stable schema version and it is optional, as stated in the Annex. So for now we decide to not include the nm field value in the DGC JSON data.

But since the field is still included (although optional) in the JSON schema, I am wondering if this choice will result in possible issues when MS business rules will be in place in order to validate DGC.

vitorpamplona commented 3 years ago

Since "nm" is required for non-NAAT tests, somebody should add nm to the test RAT example.

https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/examples/test-rat.json

gabywh commented 3 years ago

Since "nm" is required for non-NAAT tests, somebody should add nm to the test RAT example.

58

gabywh commented 3 years ago

Hi

I will try to clarify a bit on my question. The "nm" field is not associated with a value set in the current stable schema version and it is optional, as stated in the Annex. So for now we decide to not include the nm field value in the DGC JSON data.

But since the field is still included (although optional) in the JSON schema, I am wondering if this choice will result in possible issues when MS business rules will be in place in order to validate DGC.

Thanks for the clarification to your question.

HTH

lcimaglia commented 3 years ago

Ok I see now maybe was my misunderstanding about this part:

"nm": { "description": "NAA Test Name", "type": "string" },

My interpretation of description was that "nm" field was only for NAA test. From my point of view this should be corrected into

"nm": { "description": " Test name, optional for NAA Test", "type": "string" },

I think it is a minor issue but I am writing this down just to make sure my interpretation is correct.

gabywh commented 3 years ago

From my point of view this should be corrected into

"nm": { "description": " Test name, optional for NAA Test", "type": "string" },

I think it is a minor issue but I am writing this down just to make sure my interpretation is correct.

Ah, I see - and yes I agree with you, I will clarify the text - nice suggestion, thanks.

58 #59

gabywh commented 3 years ago

Debate still on-going on this one! I think we can simplify things a lot for implementers by just having one key-value reference in the DCC, and then all the other text outside of that in the valueset. I will suggest this - and hopefully resolve this (at least for the implementers side of things) once and for all

gabywh commented 3 years ago

See also: https://github.com/ehn-dcc-development/ehn-dcc-schema/pull/93#issuecomment-856283620

gabywh commented 3 years ago

Closing this one as test manf / name clarified in the up-coming v1.3.0