Page Comparison

Levert een payload op. In de FHIR specs staat dat de server zelf bepaalt of de volledige resource instantie wordt geretourneerd. 

Levert alleen header informatie, om te voorkomen dat bv bij het aanmaken van een grote hoeveelheid FHIR resources alle aangemaakte resources in de response komen, een vragende applicatie kan zelf bepalen of het response gevuld moet zijn, mbv de parameters ‘prefer’ en de waarde ‘return’, zoals beschreven in de FHIR specs.

Voor de leverancier is dit wel belangrijk, zodat ze altijd alle header informatie moeten uitlezen en verwerken voor de status, versie en locatie (url) van de resource instantie.

Bij de referentieomgeving  wordt een HTTP200 met OperationOutcome ‘successfully deleted ….’ geretourneerd.

De OperationOutcome is niet gespecificeerd bij een geslaagde operatie en bij een verwijdering van een resource instantie verwacht je geen payload in een response.

Als een operatie goed wordt uitgevoerd, hoeft alleen een HTTP status code geretourneerd te worden. Alleen bij een fout MOET er een OperationOutcome geretourneerd worden.

Na het succesvol verwijdering van een resource instantie, MOET de server ofwel een 200 OK retourneren, als het antwoord een payload bevat of een 204 No Content with no response payload.

Het makkelijkst is om een HTTP 204 te retourneren, omdat de server dan geen OperationOutcome hoeft te structureren, waar geen specificaties van zijn.

Bij de referentieomgeving wordt ook de patch en conditionele operaties ondersteund.

→ Functie is inmiddels verwijderd uit de documentatie.

FHIR heeft de patch en conditionele operaties op trial (proef) staan totdat er meer ervaring is opgedaan met het gebruik ervan. De status (wijziging) zal worden beoordeeld in toekomstige versies van FHIR.

Advies is om ze nu niet te gaan gebruiken in Koppeltaal zolang de status op trial staat.

• ACCEPT niet aanwezig. 
• HAPI accepteerde foute Content_Type. Voorbeeld: application/json 

• 406 Not Acceptable. HTTP fout bij achterwege laten van ACCEPT.
• 415 Content_type not supported. HTTP fout  bij verkeerde content_type. 

 We ondersteunen voor de Content_Type:

• XML: application/fhir+xml
• JSON: application/fhir+json

Voor zoekopdrachten (search)

• application/x-www-form-urlencoded

Wat is het verschil?

• 409. De server heeft de bron gelockt waardoor wijziging niet mogelijk is. Ook wel pessimistische locking genoemd. Kwam veel voor bij KT 1.3.x. Vanwege messaging en record locking in database. Werden berichten uitgewisseld.
• 412. Pre-conditie faalt. Als de versie-id in de If-Match niet overeenkomt. Ook wel optimistiche locking genoemd. Deze melding kan bij (FHIR) REST API PUT/PATCH-verzoeken voorkomen. Deze zou juist bij KT 2.0 voorkomen, omdat deze op REST API gebaseerd is ipv messaging.

Maakt gebruik van '_count' en navigatie links in Bundle. Standaard FHIR, maar is geen MUST maar een SHOULD voor ondersteuning van de server. Server bepaalt hier de navigatie.

Als de FHIR Resource Provider (of FHIR Store) geen Paging ondersteunt, kan er niet door een client applicatie gedoseerd door de aangeleverde resources genavigeerd worden.

Bij ondersteuning van Paging, zou de client applicatie de navigatie linkjes moeten vertalen in Navigatie Buttons op de user interface (scherm).

Authorization code flow bij OAuth2

Gegenereerde sleutel paren

Zowel HAPI als ITZOS MOETEN de volgende algoritmes kunnen ondersteunen:

RS256, RS384, en RS512 en ES256, ES384, en ES512. 

→ Zie specs TOP-KT-020.

Deze wordt in de JWT header meegegeven. Zie "alg".

HAPI retourneert HTTP401

"diagnostics": "Unauthorized" 

retourneert HTTP401

"diagnostics": "security/suppressed",

 "details": {

                          "text": "security/suppressed"

Zolang ze dezelfde HTTP 401 terug geven, betekent dat er authenticatie is vereist voor die interactie die geprobeerd is. Eis:

• De server MOET een OperationOutcome retourneren als de REST-interactie of bewerking is mislukt
• Hierin MOET informatie staan wat de reden is waarom het fout is gegaan
• Bij autorisatie fouten moet de voorziening (server) zo min mogelijk informatie weggeven. Het retourneren van te veel informatie kan details over de toegang blootleggen die NIET naar cliënten gecommuniceerd mogen worden.

Opmerking de voorziening (server)  bepaalt zelf de content van de OperationOutcome.

Itzos heeft problemen met bepaalde diakritische tekens in XML. Resulteert in foutmelding HTTP 403. Diakritische tekens in JSON worden wel goed verwerkt.

Is opgelost.

Zie voor meer informatie de FHIR specificaties op http://hl7.org/fhir/R4/structuredefinition.html#interpretation

Het is dus niet mogelijk om de volgorder hiervan te wijzigen.

Indien de FHIR resource in JSON wordt gepresenteerd, maakt de volgorde van de velden (elementen) niet uit 

Search

• De return Bundle heeft een element _total dat het aantal gevonden resources geeft dat overeenkomt met de zoekparameters.

Altijd wordt het element _total teruggeven

Parameter _total=accurate wordt door Intersystems niet ondersteund.

• Servers MOETEN paging ondersteunen voor de resultaten van een Search interactie, en als ze dat doen, MOETEN ze voldoen aan deze methode (aangepast van RFC 5005 (Feed Paging and Archiving) voor het verzenden van vervolglinks naar de client bij het retourneren van een Bundle (bijv. geschiedenis en zoeken). Als de server dit niet doet, is er geen manier om door te gaan met oproepen.

Zie:

The feed documents in a paged feed are tied together with the following link relations: 

• "first" - A URI that refers to the furthest preceding document in a series of documents. 
• "last" - A URI that refers to the furthest following document in a series of documents.
• "previous" - A URI that refers to the immediately preceding document in a series of documents.
• "next" - A URI that refers to the immediately following document in a series of documents.

Paged feed documents MUST have at least one of these link relations present, and should contain as many as practical and applicable.

Er wordt bij een search geen "last" link teruggegeven, wel "self", "next" en "previous"

Voldoet aan RFC5005. Geeft alle link relaties terug.

Een server KAN de klant informeren over het _total aantal resources dat is geretourneerd door de interactie waarvoor de resultaten worden opgeroepen met behulp van de Bundle.total. Zie vorige item. Via de "last" link kan men meteen naar het laatste record gaan. Heeft veel voordelen als het _total groot is. Graag ook "last" link retourneren bij een Search.

Het zoeken op _elementen (velden met waarden) in een resource instantie, zoals door FHIR beschreven.

Voorbeeld zoeken op identifier en active:

GET http://hapi.fhir.org/baseR4/Patient?_elements=identifier,active

Oplossing voor _elements wordt geïmplementeerd in versie 2022.2 (huidige versie is 2022.1). Probleem hertesten als versie uitgebracht is (Jira IF-2597)

Is opgelost.

AuditEvent:

Er zijn veel kleine verschillen. Bijvoorbeeld de notering van datum/tijd, en velden de niet verplicht zijn, die de ene wel veld en de ander niet. Hiernaast worden de belangrijkste verschillen genoemd.

• Bij outcome<>0 bevat OutcomeDesk de foutmelding uit OperationOutcome.
• Bij outcome<>0 bevat entity.type.code OperationOutcome.
• Entity.what.reference (bij outcome=0): resource/id/_history/versie
• Entity.query: bij alle acties met outcome=0. (Is niet correct)
• Action=R bij Search en Metadata.
• Entity.what/type/query worden bij Search voor elk gevonden item gegeven. (Is niet correct)
• Entity.what (bij delete): niet aanwezig. (Is niet correct)
• Entity.description: niet aanwezig.

• Bij outcome<>0 bevat Contained de foutmelding uit OperationOutcome. In entity.what staat dan een 'interne referentie' naar Contained.
• Bij outcome<>0 zijn er 2 entity.type.code. 1 met OperationOutcome. 1 met resource.
• Entity.what.reference (bij outcome=0): baseUrl/resource/id/_history/versie
• Entity.query: Alleen bij 'search' acties.
• Action=E bij Search en Metadata.
• Entity.what/type/query is bij Search niet aanwezig. De query geeft aan wat er gezocht werd.
• Entity.what (bij delete): bevat resource/id.
• Entity.description: "Succesfully processed request".
• Voor CapabilityStatement en Conformiteit worden geen AuditEvents aangemaakt.

• Status 'requested' wordt omgezet naar 'active', maar daarvoor wordt een nieuwe versie van de resource gemaakt.
• Channel.type = rest-hook wordt niet afgedwongen.
• Search narrowing wordt pas bij ophalen gegevens toegepast.

• Status 'requested' wordt direct omgezet naar 'active'.
• Channel.type = rest-hook wordt afgedwongen.
• Aan criteria wordt automatisch de resource-origin toegevoegd als autorisatie daar aanleiding toe geeft.
• AuditEvent.entity.what bevat voor notificaties (Transmit) de referentie naar de Subscription op basis waarvan de notificatie is verstuurd.
• AuditEvent.entity.network wordt bij notificaties gevuld met Subscription.channel.endpoint.
• Notificatie werkt niet wanneer Subscription.criteria alleen de resource bevat, bijv.: "criteria": "Task?". Dit is ook niet de bedoeling, maar het aanmaken hiervan moet nog afgevangen worden. Is als bevinding opgevoerd.

Extra specificaties Itzos omgeving zijn te vinden in document: Technical Documentation for Koppeltaal 2 Server. Te vinden op: Specificaties Itzos.

Is geheel afgeschermd i.v.m. risico's voor werking applicatieinstantie. Respons HTTP400, diagnostics:<HSFHIRErr>InteractionNotSupported, details: text:Interaction 'update' is not supported for resource type 'Device'.

In Post mag geen resource-origin worden meegegeven. Dit geeft een foutmelding.

In Put mag een resource-origin worden meegegeven, maar deze wordt toegevoegd indien niet aanwezig. Een foute resource-origin geeft een foutmelding.

Het in Post meegeven van een (foute) resource-origin wordt genegeerd. Resource wordt aangemaakt.

In Put mag een resource-origin meegegeven worden. Indien deze niet correct is, wordt deze genegeerd en de respons voorzien van een correcte resource-orgin.

• DeviceId is nieuw uitgegeven UUID.
• Het is mogelijk om een nieuw Device aan te maken zelfde ClientId en een Device te wijzigen.

• DeviceId is gelijk aan ClientId.
• Hiet is niet mogelijk om een 2e Device aan te maken voor zelfde clientId. Geeft HTTP403 Forbidden, met melding: "Key not unique: HSFHIR.X0006.R.Rsrc:KeyIdx:^HS .Local.FHIRServEC11.ResourceI(\"KeyIdx\",\"Device/<id>\")"
• Het is niet mogelijk om een Device te wijzigen. Dit geeft een HTTP400 Bad Request, met melding: "Interaction 'update' is not supported for resource type 'Device'."