Beschrijving

Om Resources binnen domeinen uit te wisselen maakt Koppeltaal gebruik van een FHIR resource service. Dit document beschrijft welke interacties er ondersteund worden.

Overwegingen

Koppeltaal maakt gebruik van een FHIR resource service. Deze service kan middels de FHIR RESTful API specificaties benaderd worden. Applicaties in een domein (applicatie-instanties) kunnen na authenticatie toegestane acties uitvoeren op de FHIR resource service. Geautoriseerde applicatie-instanties kunnen vervolgens deze informatie ophalen en waar nodig (en mogelijk) bijwerken. De resources dienen op een eenduidige manier aangemaakt en uitgewisseld te worden. Zo kunnen applicaties in het domein goed samenwerken. Ook moeten er uitbreidingen op de standaard gemaakt worden om bijvoorbeeld geautomatiseerd te voldoen aan wetgeving.

Toepassing en restricties

Profielen

Om te waarborgen dat iedereen dezelfde taal spreekt, en alle benodigde informatie voor iedereen aanwezig is, vereist Koppeltaal het gebruik van profielen. Elk toegestane resource heeft een eigen profiel. Een profiel gebruikt een StructureDefinition resource als datastructuur. Deze resource beschrijft welke eigenschappen een resource heeft, en bijvoorbeeld ook wat de kardinaliteit van elk veld is. De officiële Koppeltaal profielen zijn hier te vinden: https://simplifier.net/Koppeltaalv2.0/~resources?category=Profile&fhirVersion=R4.

De StructureDefinition resources dienen door de FHIR resource service ingeladen te worden. Applicatie-instanties mogen deze niet zelf aanmaken of bewerken.

Validatie

Zie TOP-KT-010 voor meer informatie over de validatie.

Capabilities

De FHIR resource service beschrijft de functionele mogelijkheden in de CapabilityStatement. Zie /wiki/spaces/K2/pages/17531608 en https://www.hl7.org/fhir/r4/capabilitystatement.html voor meer informatie.

FHIR RESTful API

De FHIR RESTful API biedt een groot scala aan functionaliteiten. De specificatie bevat ook optionele functionaliteiten. Binnen Koppeltaal is gekozen wat wel en niet ondersteund wordt:

Mime-Type

Ook is er een keuze gemaakt welke MIME-types worden ondersteund. Het MIME-type MOET middels de Content-Type header meegegeven worden wanneer er een resource naar de FHIR resource service gestuurd wordt.

De Accept header MAG gebruikt worden, hiervoor gelden de volgende regels:

• Indien er geen Accept header wordt meegegeven MOET de FHIR resource service uitgaan van de standaard MIME-Type ( application/fhir+json ).
• Indien er een Accept wordt meegegeven die voortkomt in de tabel hieronder MOET deze gebruikt worden.
• Indien er een Accept header wordt meegegeven die niet voorkomt in de tabel hieronder heeft de FHIR resource service een aantal opties, FHIR resource service MOET een van deze opties kiezen:
  1. De FHIR resource service kan welwillend (lenient) gaan met het MIME-Type en een match proberen te maken door bv. application/json te accepteren als application/fhir+json.
  2. De FHIR resource service kan een HTTP status code 400 (Bad Request)  of 415 (Unsupported Media Type)  terugsturen, de eerste als de MIME-Type onbekend is (bv. application/fhi+xml), de laatste als de MIME-Type wel bekend is, maar niet ondersteund wordt (bv. application/pdf). Welke MIME-Types bekend of onbekend zijn, bepaalt de FHIR resource  service zelf.
  3. De FHIR resource service kan de standaard MIME-Type gebruiken.

De MIME-Type in de Content-Type header MOET gepostfixed worden met de FHIR version en encoding:

1. application/fhir+json; fhirVersion=4.0; charset=utf-8

2. application/fhir+xml; fhirVersion=4.0; charset=utf-8

Update

Koppeltaal forceert het gebruik van de If-Match header. Dit waarborgt dat een Update altijd gebaseerd is op de laatste versie. Zo wordt de kans op dataverlies geminimaliseerd. Zie https://www.hl7.org/fhir/r4/http.html#concurrency voor meer informatie.

Delete

Koppeltaal maakt bij voorkeur geen gebruik van een DELETE request. Wanneer data niet meer gebruikt dient te worden, dient dit opgelost te worden middels een status. Zie Levenscyclus van een FHIR Resource voor meer informatie. Een DELETE request wordt wel ondersteund, maar zal een logical-delete uitvoeren.

If-Match delete

Tijdens een delete wordt de If-Match header niet afgedwongen. Functioneel ondersteunt de FHIR resource service dit wel. Het is aan de uitvoerende partij om te bepalen of het belangrijk is dat een delete gebaseerd is op de versie. Bijvoorbeeld: Een eindgebruiker kan a.d.h.v. de gegevens in een GUI een object beoordelen, en verwijderen als het een bepaalde state bevat. In dit geval is het wijs om een If-Match toe te voegen. Wanneer een systeem een batch aan resources wilt verwijderen, ongeacht de state, maf de If-Match header weggelaten worden.

Conditional Create, Conditional Update en Conditional Delete

Deze functionaliteiten zijn in de “trial use” fase. Dit houdt in dat het beproefd wordt. De implementatie wordt geëvalueerd en in een toekomstige versie pas gereviewed. Er is dus een grote kans dat deze functionaliteiten in de toekomst anders zullen gaan werken. Wel zijn deze functionaliteiten geïmplementeerd. Maak enkel gebruik van deze functionaliteiten indien er bereidheid is hier later aanpassingen in door te voeren.

Links naar gerelateerde onderwerpen

{}