Brontekst bekijken van HL7v3

==Templateversionering==
HL7v3 waaronder CDA wordt gedefinieerd op basis van templates. Deze zijn opgesteld op basis van de [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377 HL7 standaard voor templatedefinities] ''HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1''.

Templates hebben een identificatie in de vorm van een [https://www.nictiz.nl/standaardisatie/overzichten/oids/ OID] en een versie in de vorm van een [https://nl.wikipedia.org/wiki/ISO_8601 ISO 8601] tijdstempel zonder tijdzone (yyyy-mm-ddThh:mm:ss).

Templates zijn, tenzij expliciet anders gespecificeerd ''open''. Dat wil zeggen dat alleen dingen worden gespecificeerd waarvoor specificatie nodig is binnen de bekende use case(s). Deze specificaties zijn in feite een inperking op het onderliggende model waarvan de structuur normalerwijs in een XML Schema is gespecificeerd. Een zender mag meer sturen, binnen de grenzen van het onderliggende model, en een ontvanger dient deze extra informatie minimaal te kunnen negeren maar mag deze uiteraard ook verwerken.

Principes voor versionering:
* '''Backward compatibele wijzigingen''': nieuwe templateversie met behoud van het id, maar met een nieuwe versie (tijdstempel)
** Waar relevant hebben templates een verplicht {{fhir|templateId}} element waarin attribuut {{fhir|root}} matcht met het id van de gebruikte template en optioneel een attribuut {{fhir|extension}} dat matcht met de versie van het template
** Het element {{fhir|templateId}} kan meerdere keren voorkomen. Volgorde doet er toe: de meeste specifieke template eerst. Ieder {{fhir|templateId}} moet 'waar' zijn
*** Een zender moet instaan voor wat hij stuurt. Voor ieder templateId dat hij aangeeft moet gelden dat hij daarvoor de specificatie heeft gevolgd
*** Een ontvanger moet instaan voor de integriteit van zijn systeem bij verwerking van wat hij ontvangt. Hij mag op een of meerdere van {{fhir|templateId}} elementen valideren of die kloppen. Een ontvanger hoeft niet alle {{fhir|templateId}} elementen te kennen. Een ontvanger hoeft zichzelf ook niet afhankelijk te maken van aanwezigheid van {{fhir|templateId}} elementen om validatie doen. De context van ontvangst en/of context van een te valideren fragment kunnen ook aanleiding zijn om een of meerdere validatieregels uit te voeren alvorens het ontvangen bericht te verwerken.
* '''Niet-backward compatibele wijzigingen''': nieuwe template met een nieuw id en een eigen tijdstempel
** De nieuwe template kan middels een wat meer informeel {{fhir|relationship}} bijvoorbeeld van [https://art-decor.org/mediawiki/index.php?title=DECOR-rules#template.2Frelationship.2F.40type type "ADAPT"] worden gekoppeld aan zijn voorganger

Voorbeeld:
<syntaxhighlight lang="xml">
<observation>
    <templateId root="1.2.3" extension="2021-01-01T00:00:00"/>
    <templateId root="1.2.3"/>
    <!-- ... -->
</observation>
</syntaxhighlight>

In dit voorbeeld is er sprake van een {{fhir|observation}} die voldoet aan twee templatedefinities. Beide definities hebben id ''1.2.3''. De eerste zegt expliciet welke versie deze heeft. De tweede niet. De eerste is, naar verwachting, de meeste specifieke van de twee. Als de ontvanger de versie ''2021-01-01T00:00:00'' niet kent, dan valideert/verwerkt hij volgens de versie die hij wel kent. Vanwege de backward compatibile aard van versies, maakt het niet uit welke versie wordt gebruikt. De delen die de ontvanger niet kent, zal hij op die manier kunnen negeren. Dit principe garandeert een zekere mate van houdbaarheid van implementaties ten opzichte van een zekere mate van flexibiliteit in een veld waar niet alle communicatiepartners tegelijk updates doen.

<small><font color="BBB7B6">Nadere informatie over templating guidelines / templateIds staat ook nog op [[HL7v3_Templating_Guidelines|<font color="BBB7B6">deze niet definitieve werkpagina</font>]].</font></small>