Dit issue gaat over iets anders dan en is ten onrechte gesloten. Ik her-nomineer hem voor de volgende patchrelease.

Het profiel spreekt zich m.i. wel tegen.

De vraag in dit ticket was dan ook niet of de cardinaliteit van `.period.end` aangepast zou moeten worden, maar of de definition op `period` niet beter anders kan: kan de core definition niet overschreven worden om niet meer over een missende .end te spreken? Als het ook maar enige onduidelijkheid voorkomt zou dat implementers kunnen helpen.

Er is geen sprake van dat het profiel zichzelf tegen zou spreken, .period.end is op 1..1 gezet omdat EindDatumTijd in de zib verplicht is.

Na publicatie van zib 2017 is het inzicht gekomen dat kardinaliteiten in de zibs als conceptueel beschouwd moeten worden. Dit inzicht is niet met terugwerkende kracht toegepast op de informatiestandaarden of de FHIR-profielen. In de verschillende informatiestandaarden die zib-publicatie 2017 gebruiken, is Betaler::EindDatumTijd op dit moment dan ook verplicht.

Als er tijdens kwalificaties uitzonderingen worden gegeven op het meesturen van dit concept, dan moet dat daarom ook echt als uitzondering beschouwd worden. Een fout tijdens profielvalidatie is dan ook het verwachte gedrag.

Als die uitzondering afgegeven wordt op basis van het idee dat de kardinaliteit slechts conceptueel is, dan is dat niet in lijn met de informatiestandaard; als conceptuele kardinaliteiten met terugwerkende kracht toegepast worden, zal er ook een wijziging in de informatiestandaarden nodig zijn. Het verruimen van een kardinaliteit is backwards incompatible, wat betekent dat dat altijd tot een major publicatie zal leiden.

Hetzelfde geldt voor de FHIR-profielen: als die aangepast moeten worden op basis van voortschrijdend inzicht over conceptuele kardinaliteiten, zal dat leiden tot een major-publicatie van het package.

De aanpassing kan daarom niet in de patchrelease worden meegenomen.