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:
Instance Level Interactions | Ondersteund | Remark | |
|---|---|---|---|
| read | Read the current state of the resource | ✓ | |
| conditional read | Read the current state of the resource if modified since of matches ETag | ✓ | |
| vread | Read the state of a specific version of the resource | ✓ | |
| update | Update an existing resource by its id (or create it if it is new) | ⚠ | If-Match header verplicht |
| conditional update | Allows a client to update an existing resource based on some identification criteria | ⚠ | Trial use fase |
| patch | Update an existing resource by posting a set of changes to it | ✗ | Wordt mogelijk in een toekomstige versie toegevoegd |
| conditional patch | Allows a client to patch an existing resource based on some identification criteria | ✗ | |
| delete | Delete a resource | ⚠ | Bij voorkeur gebruik maken van een end-of-life status i.p.v. een delete |
| conditional delete | Allows a client to delete an existing resource based on some selection criteria | ⚠ | Trial use fase |
| history | Retrieve the change history for a particular resource | ✓ | |
| Type Level Interactions | Ondersteund | Remark | |
| create | Create a new resource with a server assigned id | ✓ | |
| conditional create | Allows a client to create a new resource only if some equivalent resource does not already exist on the server. | ⚠ | Trial use fase |
| search | Search the resource type based on some filter criteria | ⚠ | Zie ondersteunde search result parameters |
| search paging | Support paging for the results of a search or history interaction | ✓ | |
| history | Retrieve the change history for a particular resource type | ✓ | |
| Whole System Interactions | Ondersteund | Remark | |
| capabilities | Get a capability statement for the system | ✓ | |
| batch/transaction | Update, create or delete a set of resources in a single interaction | ✗ | |
| history | Retrieve the change history for all resources | ✗ | |
| search | Search across all resource types based on some filter criteria | ✗ |
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. Ook MAG de Accept header gebruikt worden. In dat geval MOET een onderstaande MIME-type als waarde gezet worden.
| MIME-type | Geïmplementeerd | Remark |
|---|---|---|
| application/fhir+json | ✓ | |
| application/fhir+xml | ✓ | De xsd schema’s voor de validatie dwingen een specifieke volgorde af (xs:sequence) |
| application/fhir+turtle | ✗ |
De MIME-Types MOETEN gepostfixed worden met de fhir version en encoding:
application/fhir+json; fhirVersion=4.0; charset=utf-8
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.
Recht op vergetelheid
In een aantal gevallen mag een gebruiker aan een organisatie vragen om alle (historische) gegevens, van die gebruiker, uit hun systeem te verwijderen.
Voor het fysiek verwijderen van resources hebben sommige FHIR Resource Providers een $expunge functionaliteit geïmplementeerd. Deze functie verwijdert alle versies van een resource uit de FHIR Store.
De $expunge operatie is echter GEEN STANDAARD (FHIR RESTfull) operatie, en moet apart geïmplementeerd worden voor de FHIR Store. Deze operatie mag alleen op instance-level aangeroepen worden.
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, Conditional Delete en Conditional Patch
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
| Beschrijving | Link | Opmerking |
|---|---|---|
| FHIR RESTful API documentatie | https://www.hl7.org/fhir/r4/http.html | |
| FHIR concurrency met If-Match | https://www.hl7.org/fhir/r4/http.html#concurrency | |
| If-Match enforce code voorbeeld | https://github.com/Koppeltaal/Koppeltaal-2.0-FHIR-HAPI-Server/blob/master/src/main/java/ca/uhn/fhir/jpa/starter/koppeltaal/interceptor/EnforceIfMatchHeaderInterceptor.java | Deze code filtert ook PATCH requests en Bundles. Deze worden binnen Koppeltaal niet gebruikt. |
| Voorbeelden van alle Resources in JSON en XML | https://simplifier.net/Koppeltaalv2.0/~resources?category=Example&fhirVersion=R4 | |
| FHIR search specificatie | https://www.hl7.org/fhir/r4/search.html | |
| FHIR paginatie | https://www.hl7.org/fhir/r4/http.html#paging |