Minutes

this is possible but however there is no real use for it. The transit info should be used to transform the pseudonym to its eventual form, because the pseudonym is different for every transmission. This form is not suitable to be stored or processed otherwise.
On top, this will impact the validation of pseudonymized and non-pseudonymized resources, because of the additional slice to be added to pseudonymizable resources.
extensions are not preferable, what if you don't store it ; but pseudonymized is not an unique identifier so it could not be used this way
what about blinding/unblinding (see cookbook): not clear yet

Each pseudonym has its own transit info, even if you use the “multiple” functionality

size of getRequest is limited, however there is an alternative in the FHIR standard, using post syntax
search can done using POST and POST url syntax because of the size of the search parameters
how will we express the parameters ? There are 2 options:

treat parameter as composite parameter using a separate token, concatenation using a $ sin
encode pseudonym in a JWE string, this will have a double impact of Base64 encoding

Security controls: continue work on valuesets by Brecht
Position of HL7 Belgium on the FHIR R5 release (to cover the already upcoming questions from players and stakeholders in Belgium)
FHIR readiness of Belgian metahub-hub system: see preparation work

Anonymous