eHealth Network DCC Schema 1.3.3

Changes:

• Update the sub schema DCC.ValueSets.schema.json for the new valueset vaccine-encoding-instructions corresponding to Annex A of (version 1.14 of) guidelines document.
  • Also synchronize the description field of each valueset with v1.14 of the eHN EU DCC Value Sets Guidelines document.
• Move contents of GitHub Wiki - mainly the FAQ - to a wiki/ folder, to use one mode of persisting knowledge.
• Improve the description of the person_name schema definition.
• Implement a pre-commit Git hook that prevents committing when tests fail, or when the sub schemas haven't been properly merged into the combined schema.
• Commit NPM artifacts (package*.json) to shrinkwrap dependencies' versions.

Note: none of these changes modify the effective JSON Schema for the EU DCC in any way.
They are simply improvements intended to benefit the longevity of this repository and the EU DCC standard.

eHealth Network DCC Schema 1.3.2

Changes:

• The elements fnt and gnt are now optional, with one of the two being required. This conforms to the latest Implementing Decision 2022/483. (The changes are in ANNEX II chapter 3.2.).
• Examples and tests are updated for these new cases (and for several different sequences).
• merge.py now outputs un-HTML-encoded text in modern Python.

eHealth Network DCC Schema 1.3.1

The valuesets have grown up and now have a home of their own at https://github.com/ehn-dcc-development/ehn-dcc-valuesets.
The valuesets were temporarily placed in this repository are now removed with this patch release.
Please refer to https://github.com/ehn-dcc-development/ehn-dcc-valuesets for the authoritative source for the valuesets.

(Also: added missing descriptions for tg fields.)

eHealth Network DCC Schema 1.3.0

Overview

This 1.3.0 release of the eHealth Network Digital COVID Certificate (DCC) JSON Schema is based on the approved eHealth Network document 1.3.0 JSON Schema

Main Functional Changes

A brief overview of the main functional changes are given here. As ever, the truth is in the source code, so a diff between the versions will give you the exact details.

For more detailed information concering a particular version, please consult the releases webpage.

1.3.0 Compared to Release 1.2.1

• General: much clearer spec as to exactly what data to place in each of the schema fields, thanks to the 1.3.0 JSON Schema document
• Only one medical event - vaccination or test or recovery - per schema instance
• Support for an empty date of birth
• Testing Centre or Facility (`t/tc') optional for Rapid Antigen Tests (RATs).

1.3.0 Compared to Release 1.0.x

• As for 1.2.1 -> 1.3.0 plus
  • Field Date of Test Result (dr) dropped
  • Support for partial Date of Birth
  • Filenames and $refs changed from DGC to DCC

Digital Green Certificate -> Digital Covid Certificate

Name Change: Digital Green Certificate becomes Digital Covid Certificate

In line with the latest EU /eHealthNetwork naming conventions, Digital Green Certificate -> Digital Covid Certificate (and thus DGC -> DCC).

There never really is a good time to make such changes as renaming files, so the sooner the better in an attempt to minimize the pain associated with this change.

Documentation

• Digital Green Certificate -> Digital Covid Certificate (DGC -> DCC)

JSON files

• Filenames changed: DGC -> DCC
• $refs in JSON content changed: DGC -> DCC

Test Certificate field "dr"dropped

Test result date (field "dr") has been removed from the data set in the recent version of the regulation.
Recovery certificate is based only on the NAA test result.

DGC: Relax Date Of Birth check

It is a standard case that for date of birth either the full date (YYYY-MM-DD) is known, or just an (often estimated) year (YYYY) (e.g. FHIR Patient.birthDate). It can also be the case, but less frequently occuring, that year and month only (YYYY-MM) are known.

The DGC schema must be able to support all cases as valid.

Applying the first part of Postel's law: the DGC schema should accept anything that at least has 4 consecutive decimal digits at the beginning, since we can then interpret this at the minimum as a year. In order to filter out a lot of noise with random values, we can reasonably limit the year range from 1900 to 2099, A simple regex suffices here.

Applying the second part of Postel's law: note as already mentioned elsewhere (https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/README.md, https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ#issuance-of-qr) that it is the primary responsibility of the issuance business rules to generate clean data for submission to the DGC payload.

First public release

Merge pull request #55 from ehn-digital-green-development/next

Prepare for 1.0.0