warning instead of errors for GLN, EPR-SPID, AHVN13 and VEKA datatype profiles

[oliveregger]

In CH ELM we have a Use Case where we wan't to allow "invalid" GLN's and AHVN13 and not have an invalid exchange format, therefore we would like that in the base profiles the business rules for datatypes would give only a warning and not an error.

https://fhir.ch/ig/ch-core/StructureDefinition-ch-core-gln-identifier.html
gln-length
gln-modulus-10
gln-startswith7601

https://fhir.ch/ig/ch-core/StructureDefinition-ch-core-ahvn13-identifier.html
ahvn13-digit-check
ahvn13-length
ahvn13-startswith756

https://fhir.ch/ig/ch-core/StructureDefinition-ch-core-veka-identifier.html
https://fhir.ch/ig/ch-core/StructureDefinition-ch-core-epr-spid-identifier.html

[oliveregger]

15 - 0 - 0

[jkiddo]

@oliveregger why the GLN matchdowngraded to a warning? If you have a use case where it does not fit the requirements then dont use it, would be my suggestion.

[oliveregger]

@jkiddo we want to apply the ch core profile to all use cases and we have experienced now multiple times that we cannot enforce errors or min cardinality already on the core profiles, too strict for downstream implementations ....

[jkiddo]

@oliveregger Why not let the use of the identifier be optional instead then in those cases? The invariant enforces more explicitly what any client/user should already be aware of when using the GLN OID in the identifier.system.

[oliveregger]

the identifier is optional, however used in the slicing in core. as soon as you have a GLN on the wire, the validator will apply the constraint and generate the error ...

[jkiddo]

Well - you should not be using the identifier if the input doesnt qualify, right? And one has all the options to validate the contents ahead of hitting the wire, correct?