Page Comparison

Het is zeer onwaarschijnlijk dat een Koppeltaal interface ongewijzigd blijft. Als de Koppeltaal eisen in der loop ter tijd  veranderen, kunnen er nieuwe verzamelingen van FHIR resources, profielen en interacties worden toegevoegd, kunnen de relaties tussen de resources veranderen en kan de structuur van de gegevens in de resources worden gewijzigd.

...

Versiebeleid zorgt ervoor dat elke wijziging of aanpassing van een configuratie item Configuratie Item (CI) een gedefinieerde versie heeft voor belanghebbenden.  De volgende CI worden    

De aanpassingen die aan een Koppeltaal interface of FHIR profiel (CI) wordt gedaan, kunnen in 2 categorieën worden onderverdeeld:

...

Het is afhankelijk van de implementatie wanneer een wijziging breaking of niet breaking is. Wanneer bijvoorbeeld validatie wordt toegepast op inkomende berichten en de aanroepende partij hanteert een ander versienummer dan de ontvangende partij waarbij in het bericht een element is toegevoegd, zal bij de ontvangende partij het bericht niet verwerkt worden door deze validatie. Om te voorkomen dat alle wijzigingen breaking zijn, is de keuze gemaakt om elementen in de resources optioneel te maken zodat verschillende Minor en Build versies kunnen communiceren met elkaar of te wel backwards compatible blijven. Bij integratie is het verstandig dat partijen ervan uit gaan dat wijzigingen breaking zijn en dat hiermee rekening moet worden gehouden in de implementatie. 

De volgende paragrafen beschrijven verschillende benaderingen hoe om te gaan met verschillende versies, die allemaal hun eigen BELANGRIJK:

Er is nog geen (officieel) besluit genomen HOE we met verschillende versies van (FHIR) REST APIs en (FHIR) resources (profielen) om zullen gaan. Op deze pagina worden de verschillende benaderingen bekeken en beschreven wat de voor- en nadelen hebbenzijn.

Geen versiebeheer

Dit is de eenvoudigste manier en mogelijk acceptabel voor een aantal (interne) Koppeltaal interfaces. Belangrijke wijzigingen kunnen worden weergegeven als nieuwe resources of nieuwe koppelingen. Als u optionele elementen toevoegt aan bestaande FHIR resources, is er mogelijk geen wijziging die problemen geeft, omdat cliënt toepassingen die deze elementen niet verwachten te zien, dit zullen negeren.

...

 GET https://koppeltaal.nl/fhir/Patient/61

{
    "resourceType": "Patient",   
    "id": "61",
    "identifier":  [
        {
            "use": "official",
            "system": "irma",
            "value": "berendbotje01@vzvz.nl"
        }
    ],
    "active": true,
    "name":  [
        {
            "text": "Berend Botje",
            "family": "Botje",
            "given":  [
                "Berend"
            ]
        }
    ],
    "birthDate": "1970-12-20" 
}
  

Als het optionele element "gender" wordt toegevoegd aan de resource instantie zouden bestaande toepassingen goed moeten blijven werken als ze in staat zijn om niet-herkende elementen te negeren, terwijl nieuwe toepassingen kunnen worden ontworpen voor het afhandelen van dit nieuwe element. Als echter ingrijpender (verplichte) wijzigingen in het schema van de resources optreden (zoals verwijderen of wijzigen van elementen) of de relaties tussen resources worden gewijzigd, kan dit bestaande toepassingen zodanig beïnvloeden dat deze niet meer correct werken. In deze (Major) situaties moet u één van de volgende benaderingen overwegen.

URI-versiebeheer

Telkens wanneer een Koppeltaal interface wijzigt of het schema van de resources wordt aanpast, voegt men een uniek (major) versienummer toe aan de URI voor elke (FHIR) resource. De bestaande URI's moeten blijven functioneren als voorheen en resources retourneren die voldoen aan hun oorspronkelijke schema.

Als het vorige voorbeeld wordt uitgebreid, met een verplicht element zoals bijvoorbeeld "gender", kan deze nieuwe versie van de resource worden blootgesteld via een URI met eenversienummer, zoals https://koppeltaal.nl/fhir/v2/Patient/61 

Dit mechanisme voor versiebeheer is zeer eenvoudig, maar is afhankelijk van de FHIR Resource Provider die de aanvraag naar het juiste eindpunt moet doorsturen. Dit mechanisme kan onhandig worden als de Koppeltaal interface via verschillende iteraties groeit en de FHIR Resource Provider een aantal verschillende versies moet ondersteunen. Vanuit het oogpunt van een purist halen de toepassingen in alle gevallen dezelfde gegevens op (Patient 61), dus de URI mag niet echt verschillen, afhankelijk van de versie. FHIR referenties wordt door dit mechanisme ook ingewikkelder, omdat alle referenties het versienummer moeten opnemen in hun URI's.

Header-versiebeheer

In plaats van het versienummer in het URI toe te voegen, kan men een aangepaste (HTTP) header implementeren die de versie van de resource aangeeft. Deze aanpak vereist dat de toepassing de juiste header toevoegt aan alle aanvragen, hoewel de code voor het verwerken van de aanvraag een standaardwaarde (versie 1) kan gebruiken als de versie-header wordt weggelaten. In het volgende voorbeelden wordt een aangepaste header met de naam Custom-Header gebruikt. De waarde van deze header geeft de versie van de Koppeltaal interface aan.

GET https://koppeltaal.nl/fhir/Patient/61 HTTP/1.1

Custom-Header: Koppeltaal-version=2

Net als bij de vorige benadering moet men voor het implementeren van FHIR referenties de juiste aangepaste header in koppelingen toevoegen.

Mediatype-versiebeheer

Wanneer een cliënt toepassing een HTTP GET-aanvraag naar de FHIR Resource Provider verzendt, moet deze de indeling van de inhoud bepalen die het kan verwerken met behulp van een Accept-header. Vaak is het doel van de Accept-header ervoor te zorgen dat de cliënt toepassing op kan geven of de inhoud van het antwoord XML, JSON of een andere algemene indeling moet zijn, die door de cliënt kan worden verwerkt. Het is echter mogelijk aangepaste media typen te definiëren met informatie voor het inschakelen van de cliënt toepassing, om aan te geven welke versie van een FHIR resource wordt verwacht.

In het volgende voorbeeld is een aanvraag met een Accept-header met de waarde application/koppeltaal.adventure-works.v2+json. Het koppeltaal.adventure-works.v2-element geeft bij de FHIR Resource Provider aan dat versie 2 van de resource aan de cliënt toepassing moet worden geretourneerd, terwijl het json-element aangeeft dat de indeling van de inhoud JSON moet zijn.

De code voor het verwerken van de aanvraag is verantwoordelijk voor de verwerking van de Accept-header en het zo veel mogelijk naleven ervan (de cliënt toepassing kan verschillende indelingen opgeven in deAccept-header. In dat geval kan de FHIR Resource Provider de meest geschikte indeling voor de inhoud kiezen). De FHIR Resource Provider bevestigt de indeling van de gegevens in de inhoud met behulp van de Content-Type-header.

Als de Accept-header geen bekende media typen opgeeft, kan de FHIR Resource Provider een antwoordbericht HTTP 406 (Niet aanvaardbaar) genereren, of een bericht retourneren met een standaard-mediatype. Deze aanpak is misschien de zuiverste van de verschillende methoden voor versiebeheer en is van nature geschikt voor FHIR referenties, dat het MIME-type van gerelateerde gegevens in links naar resources kan opnemen.

...