Document toolboxDocument toolbox

TOP-KT-002 - Basis interacties - [oud]

Beschrijving

De basis voor alle (technische) interacties in Koppeltaal 2.0. is op FHIR RESTful API gebaseerd.

De basis principes van REST

  • REST geeft elke resource een ID (identifier). Alles wat identificeerbaar moet zijn, moet een ID hebben. REST noemt deze identificeerbare dingen 'resources'. Op internet is er een uniek concept voor ID's: de URL. URL's vormen een globale naam en het gebruik van URL's om de belangrijkste resources te identificeren, betekent dat ze een unieke, globale ID krijgen.
  • REST is een client-server-architectuur. De server manipuleert en slaat informatie op en stelt deze op efficiënte wijze ter beschikking aan gebruikers. De client of afnemer van een dienst neemt die informatie over en toont deze aan de gebruiker en/of gebruikt deze om latere informatie verzoeken uit te voeren. Deze scheiding van taken stelt zowel de client als de server in staat om onafhankelijk verder te evolueren, omdat het hier alleen vereist wordt dat de interface hetzelfde blijft.
  • REST zorgt voor een uniforme interface tussen de (systeem)componenten. Dit vereenvoudigt de architectuur, omdat alle componenten dezelfde regels volgen om met elkaar te praten. Het maakt het ook gemakkelijker om de interacties tussen de verschillende (systeem)componenten te begrijpen. Om dit goed te bereiken hebben we een aantal randvoorwaarden nodig. Zie de basis CRUD verderop.
  • REST gebruikt meerdere representaties. Een representatie is een formaat waarin de gegevens worden getransporteerd tussen client-server. Met behulp van HTTP-protocollen kan een client vragen om een weergave in een bepaald formaat. REST staat meerdere representaties voor een resource toe. JSON en XML zijn de gebruikte representaties binnen Koppeltaal.
  • REST is stateless. Dat betekent dat de communicatie tussen de client en de server altijd alle informatie bevat die nodig is om een aanvraag uit te voeren. Er is geen sessiestatus op de server, deze wordt volledig aan de kant van de client bijgehouden. Als toegang tot een resource authenticatie vereist, dan moet de client zichzelf bij elk verzoek authentiseren, d.m.v. een toegangstoken.

Basis interacties met een server of andere applicatie moeten volledig worden aangestuurd door hypermedia (links-URLs). De client heeft geen voorkennis van de dienst nodig om deze te gebruiken, behalve een toegangspunt (endpoint) en natuurlijk basiskennis van het mediatype van de representaties, in ieder geval voldoende om hyperlinks en linkrelaties te vinden en te identificeren.

Onderstaand interactiediagram, beschrijft een data-uitwisselingspatroon waar alle functionele interacties op gebaseerd zijn:


Actor

Omschrijving

ApplicationEen (software) toepassing
SourceVerstuurt nieuwe, gewijzigde en verwijderde FHIR Resources naar de Sink
SinkOntvangt nieuwe, gewijzigde en verwijderde FHIR Resources van de Source, en slaat deze op in de Store
StoreMaak opgeslagen resources beschikbaar aan Consumers. Elke wijziging in de Store wordt ook gemeld aan de Publisher.
ConsumerLeest FHIR Resources van de Store

Subscriber

Abonneert zich op het ontvangen van wijziging notificaties door het versturen van een Subscription resource naar de Publisher.

Publisher

Verstuurt op basis van resource wijzigingen zoals gemeld door de Store en de actieve Subscriptions Notificaties met een lege body naar de RestHook van de Subscribers.

De FHIR Resource Provider combineert de Sink, Store en Publisher. Elke applicatie kan een combinatie van de technische actoren Source, Consumer en Subscriber implementeren.  

Technische Interacties

Koppeltaal Interactie

Omschrijving

FHIR-Write

Gebruikt een van de volgende FHIR Interacties (gebaseerd op http://hl7.org/fhir/http.html):

FHIR Interaction

Omschrijving

createCreëer een nieuwe resource instantie, met een server toegekende id (en een resource-origin* referentie extensie voor Koppeltaal)
update

Wijzig een resource instantie via zijn id (indien niet aanwezig wordt de instantie gecreëerd).

Als de client een wijziging wil doorvoeren op een bepaalde resource instantie , dient deze de aanvraag in te dienen met een If-Match header die de ETag van de server citeert.

Bij een update moet in het meta.profile element het profiel van de resource instantie meegestuurd worden voor validatie.

delete

Verwijder de resource instantie.

Als de client een resource instantie wil verwijderen, dient deze de aanvraag in te dienen met een If-Match header die de ETag van de server citeert.

patch (na KT 2.0)

Wijzig een resource instantie door alleen de wijzigingen op te sturen.

Als de client een partiele wijziging wil doorvoeren op een bepaalde resource instantie , dient deze de aanvraag in te dienen met een If-Match header die de ETag van de server citeert.

Voorstel is om dit pas na Koppeltaal 2.0 op te pakken omdat er meerdere soorten patchen zijn voor XML, JSON en FHIR Patch.

Zie ook: https://www.hl7.org/fhir/http.html#patch

batch/transaction

(Na KT 2.0)

Update, create of delete van een bundel resources in een enkele interactie. Niet ondersteunen in KT 2.0.
  • Elke nieuwe FHIR Resource instantie krijgt door de server een 'resource-origin' element als extensie toegevoegd, waarin bijgehouden wordt wie de originele eigenaar is van de gecreëerde resource instantie. Dit is specifiek voor Koppeltaal uitgewerkt.
FHIR-Read

Gebruikt een van de volgende FHIR Interacties (gebaseerd op http://hl7.org/fhir/http.html):


FHIR Interactie

Omschrijving

search

Zoeken op een resource type, gebaseerd op een filter criteria 

Voorbeeld:

GET /Patient?family=Botje

GET /ActivityDefinition?url:below=http://localhost/ActivityDefinition/ 

read

Lees de huidige resource instantie

Voorbeeld:

GET /Patient/3

GET /Patient?_id=3

vread

Lees een specifieke versie van een resource instantie

Voorbeeld:

GET /Patient/3/_history/2

FHIR-Subscribe

Dit is een FHIR-Write interactie op de Subscription resource met Subscription.channel.payload is null (geen body).

RestHook-Notificatie

Dit is een notificatie zoals beschreven bij REST Hook.

De REST-Hook channel type geeft aan dat de FHIR Resource Provider een HTTP REST aanvraag naar een FHIR-eindpunt moet maken wanneer een resource verandert die overeenkomt met het opgegeven Subscription resource.

De FHIR Resource Provider moet de eventuele headers toevoegen aan het POST-verzoek dat hij aan de client doet.

FHIR-Launch

Via de FHIR-Launch interactie kan een applicatie (binnen of buiten de gebruikersinterface) een andere applicatie opstarten.

Gebruikt een van de volgende FHIR-Launch Interacties:

  1. SMART App Launch Framework. Dit framewerk verbindt applicaties van derden met EPD (patiënt) gegevens, waardoor applicaties binnen of buiten een behandelingscontext kunnen worden opgestart. Het biedt een betrouwbare, veilige autorisatie protocol voor een verscheidenheid aan use cases waaronder applicaties die op een platform van een eindgebruiker worden uitgevoerd en applicaties die op een beveiligde server worden uitgevoerd. De Launch context in dit framework bestaat uit een opaque (betekenisloze) parameter. Een server kan beslissen welke startcontextparameters moeten worden verstrekt, waarbij het verzoek van de klant wordt gebruikt als input voor het besluitvormingsproces. Het SMART App Launch Framework ondersteunt 4 belangrijke use cases:
    1. Patiënten-apps die zelfstandig worden gestart
    2. Patiënt-apps die worden gestart vanuit een portaal
    3. Provider-apps die zelfstandig worden gestart
    4. Provider-apps die starten vanuit een portaal
  2. SMART HTI Launch Framework. In dit framewerk wordt tijdens de launch een HTI token meegestuurd. HTI staat voor Health Tools Interoperability en is een JSON Web Token die als informatiedrager gebruikt wordt. HTI heeft een vaste launch context formaat en maakt gebruik van een signing technologie, zodat de integriteit en authenticiteit van de launch content gewaarborgd blijft. Dit framewerk wordt gebruikt om de gebruiker zijn activiteiten te laten uitvoeren in de context van eenzelfde taak. Hiermee kan een gelanceerde module een launch interpreteren als een vorm van authenticatie. Als een gebruiker echter gevoelige of medische data heeft ingevoerd in de module, volstaat een HTI launch niet als authenticatie van voldoende betrouwbaarheid voor toegang tot deze gegevens.
FHIR InteractieOmschrijving
launch

Start een applicatie op in de context van een behandeling.

Voorbeeld:

  1. GET /application/launch?iss=https://application/source&launch=123 
  2. POST  /application/launch?iss=https://application/source&launch=HTIToken

Belangrijk:

Bij de 1e omschrijving kan men de SMART App Launch flow volgen, zie http://hl7.org/fhir/smart-app-launch/app-launch.html#launch-app-ehr-launch.

Bij de 2e omschrijving MOET het HTIToken digitaal ondertekend worden door de lancerende partij en gevalideerd worden door de gelanceerde partij. De gelanceerde partij kan het HTIToken zelf valideren of kan hiervoor een Token Introspection interface gebruiken. Zie Token Introspection

SSO bij HTIToken

SSO

Single Sign-On bij FHIR Launch.

  1. Bij KT 2.0 worden de applicatie instanties geïdentificeerd en geauthentiseerd op basis van hun applicatie rol. Dus de gelanceerde applicatie neemt NIET de rol over van de lancerende applicatie, maar deze zijn van te voren vastgelegd in bevoegdheden per rol (autorisatie matrix).
  2. Nadat een applicatie instanties gestart/gelanceerd is, kan deze met zijn eigen ondertekend authenticatie token en de aangeleverde launch context of HTIToken een toegangstoken (access-token) opvragen. Indien we gebruik maken van een launch context, wordt in de response van de autorisatie aanvraag, de context (zoals de gebruiker van de gelanceerde applicatie) gegeven. Bij het HTIToken, zal de gebruiker in het token meegestuurd worden.
  3. Met het toegangstoken (access-token) kan de gelanceerde applicatie vervolgens de FHIR Resource Provider bevragen. 
  4. Naast het toegangstoken (access-token) kan men optioneel ook een id-token van een gebruiker meesturen. Dit token wordt verkregen via een authenticatie sessie (zie OIDC- OpenID Connect protocol) en "Authentication using the Authorization Code Flow". Hierbij moet de scope in het verzoek gevuld worden met "scope=openid". OIDC wordt momenteel nog niet door Koppeltaal ondersteund. Zie ook: https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint

De URL opbouw

URL's maken het mogelijk om alle FHIR resource instanties via een netwerk te kunnen identificeren. REST legt de nadruk op een consistent definitie van deze URL's, zodat ze voor zichzelf spreken, intuïtief zijn en gemakkelijk op te bouwen zijn door applicatie instanties. Om tot een consistente manier te komen om URL's te definiëren, moeten ze zorgvuldig worden ontworpen, vandaar hier een paragraaf over de URL opbouw en het gebruik ervan.

Voordat we ingaan op de kern van de URL opbouw, wordt eerst de  verschillende onderdelen van de URL opbouw uitgelegd.
Een URL heeft de volgende opbouw : schema://domein:poort/pad?query_string. Zie ook RFC-3986.

Waar:

  • Het schema definieert de contexttype van de URL, het doel en de syntaxis van het resterende deel van de URL. De software zal proberen een URL te verwerken volgens het schema en de context. Bijvoorbeeld, een webbrowser zal gewoonlijk de verwijzing naar de URL http://voorbeeld.nl:80 verwijderen door een HTTP verzoek uit te voeren aan de host op voorbeeld.nl, met poortnummer 80. Andere voorbeelden van schema namen omvatten https:, gopher:, wais:, ftp:.
  • Het domein of IP-adres geeft de bestemming locatie voor de URL. Het domein koppeltaal.nl, of het IP-adres aa.bb.ccc.dd, is het adres van de website van Koppeltaal. Het domeinnaamgedeelte van een URL is niet hoofdlettergevoelig omdat DNS hoofdletters negeert: https://koppeltaal_acc.provider.nl/ en
    HTTPS://KOPPELTAAL_ACC.PROVIDER.NL/ openen beide dezelfde pagina.
  • De poort is optioneel; indien deze wordt weggelaten, wordt de standaardwaarde voor het schema gebruikt. Bijvoorbeeld, http://vnc.voorbeeld.nl:5800 maakt verbinding met poort 5800 van vnc.voorbeeld.nl, wat geschikt is voor een VNC-afstandsbedieningssessie. Als het poortnummer wordt weggelaten voor een http: URL, maakt de browser verbinding op poort 80, de standaard HTTP-poort. De standaardpoort voor een https: verzoek is 443.
  • Het pad wordt gebruikt om de gevraagde (FHIR) resources voor een bepaalde organisatie/zorg afnemer te specificeren en deze te vinden. Deze is wel hoofdlettergevoelig, hoewel het door sommige servers als hoofdletterongevoelig kan worden behandeld, vooral die op Microsoft Windows gebaseerd zijn. In het pad kan ook een major versie opgenomen worden zie Versiebeheer en -beleid.
    Pad voorbeeld: /zorgafnemerXYZ/v3/Patient/1234
  • De query_string bevat gegevens die moeten worden doorgegeven aan software die op de server draait. Het kan naam/waarde-paren bevatten, bijvoorbeeld gescheiden door ampersands first_name=Koppel&last_name=Taal.

Belangrijk:

Bepaalde karakters zijn in de query_string NIET toegestaan. Deze MOETEN door een escape sequence, een procentteken "%" gevolgd door twee hexadecimale cijfers (0-9, A-F) die de waarde voor dat karakter (octet waarde) aangeven, vervangen worden.

Zie de volgende BNF notatie voor de query_string:

schema://domein:poort/pad?query_string

  • query_string = xalphas [ + search ]
  • xalpha = alpha | digit | safe | extra | escape
  • alpha = a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
  • digit = 0 |1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
  • safe = $ | - | _ | @ | . | & | + | -
  • extra = ! | * | " | ' | ( | ) | ,
  • escape = % hex hex

Dus de karakters ‘:’ , '/', '?', '#', '[', ']', ‘|’, ';'  en  '=' MOETEN in de query_string omgezet worden naar %3A , %7C en %3D, zie de escape (en asciitable.com voor translatie).

Voorbeeld:

URI voorbeeld
GET https://koppeltaal_acc.provider.nl/zorgafnemerXYZ/v3/Patient?identifier=urn:oid:2.16.840.1.113883.16.3.4.2.6|KT20-116 

wordt deels ge-escape ...

GET https://koppeltaal_acc.provider.nl/zorgafnemerXYZ/v3/Patient?identifier=urn%3Aoid%3A2.16.840.1.113883.16.4.3.2.6%7CKT20-116

Content-Type

De Content-Type (HTTP) header wordt gebruikt om het mediatype (of inhoud type) van de resource aan te geven. In reacties vertelt een Content-Type-header de klant wat het content-type van de geretourneerde content eigenlijk is.

De Content-Type is een samengestelde string en bestaat uit

  • het media-type (application/fhir+xml of application/fhir+json content),
  • karakter encoding standaard (utf-8) en
  • de gebruikte FHIR resource versie die uitgewisseld wordt (fhirVersion=4.0) .


Voorbeeld:
Content-Type

Content-Type: application/fhir+json; fhirVersion=4.0; charset=utf-8

UTF-8

De FHIR (Resource) Provider ondersteunt alleen utf-8 karakters. Resources die andere karakters bevatten worden afgekeurd of afgewezen.

Representatie

Voor de representatie van de FHIR resources wordt JSON (application/fhir+json)of XML (application/fhir+xml)gebruikt.

JSON

  • De JSON representatie voor een (FHIR) resource is gebaseerd op RFC8259
  • element namen zijn hoofdlettergevoelig en UNIEK
  • De volgorde van de elementen van een (resource) object is niet significant in een JSON-representatie, hoewel de volgorde binnen een array MOET worden gehandhaafd
  • string elementen MOGEN NIET leeg zijn en moeten met minimaal 1 karakter gevuld zijn
  • Er bestaan geen namespaces in JSON 
  • JSON-elementen met '_' voor de naam van het element, worden gebruikt bij id en/of extensies, als deze aanwezig zijn. Voorbeeld:


    <birthDate id="314159" value="1970-03-30" >
      <extension url="http://example.org/fhir/StructureDefinition/text">
        <valueString value="Easter 1970"/>
      </extension>
    </birthDate>

    "birthDate": "1970-03-30",
      "_birthDate": {
        "id": "314159",
        "extension" : [ {
          "url" : "http://example.org/fhir/StructureDefinition/text",
          "valueString" : "Easter 1970"
         }]
       }

  • De volgende karakters MOETEN in JSON ge-escape worden:
    1. backspace \b of \u0028
    2. formfeed: \f of \u002C
    3. newline: \n of \u002A
    4. carriage return: \r of \u0045
    5. tab: \t of \u0029
    6. dubbele quote:  \" of \u0022
    7. backslash: \\  of \u005C
    8. forward: \/ of  \u002F
    9. separator: \r of \u003E


2 dubbele quote voorbeelden met utf-8 karakterset : ""Iñtërnâtiônàlizætiøn""

Voorbeeld:

JSON Patient
{
	"resourceType": "Patient",
	"contact":  [
		{
    		"name": {
                "text":"\"Iñtërnâtiônàlizætiøn\u002"
            }
		}
	]
}

XML

  • De XML representatie voor (FHIR) resources zijn vastgelegd in een basisschema "fhir-base.xsd" en definieert alle datatypes en basis infrastructuur types. Daarnaast is er een schema voor elke resource en een algemeen schema fhir-all.xsd dat alle (FHIR) resource schema's omvat. Voor schemaprocessors die niet van circulaire include houden, is er een enkel schema dat alles bevat.
  • Resource en element namen zijn hoofdlettergevoelig
  • Elementen moeten altijd in de gedocumenteerde volgorde verschijnen
  • Wanneer een element mag worden herhaald, worden de elementen geordend en moet de technische infrastructuur in de juiste volgorde toegang hebben tot de items
  • Sommige properties mogen als attributen worden gepresenteerd, waarden van primitieve typen in een 'value' attribuut, extensie-URL's in het 'url' attribuut op een extensie en de 'id' property op elementen (maar niet op resources, waarbij de resource-ID een element is)
  • FHIR elementen zitten altijd in de 'http://hl7.org/fhir' namespace
  • FHIR elementen en attributen zijn nooit leeg
  • De volgende karakters MOETEN in XML ge-escape worden:
    1. ":   &quot; of &#342;
    2. ':   &apos; of &#393;
    3. <:   &lt; of &#604;
    4. >:   &gt; of  &#625;
    5. &:   &amp; of &#38;

Toegestane karakters XML v1.0.

Char   ::=   #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */


Voorbeeld:

XML Patient
<Patient xmlns="http://hl7.org/fhir">
	<contact>
		<name>
        	<text value="&quot;I&#241;t&#235;rn&#226;ti&#244;liz&#230;ti#248;n&quot;"/>
        </name>
	</contact>
</Patient>

Resource Bundle

Elke interactie die resulteert in, of die een verzameling resources aanbiedt, wordt uitgevoerd via een resource Bundle mechanisme. Een FHIR Bundle resource is een verzameling resources die gerelateerd zijn, bijvoorbeeld het resultaat van een zoekactie, of een verzameling van historische versie van een resource.

De resource Bundle wordt beschreven in FHIR http://hl7.org/fhir/R4/bundle.html.

Response op interacties in de HTTP headers


HTTP headers
Content-LocationURL van de (nieuwe) resource, resource id, bijvoorbeeld '1234'
Content-TypeResource serialization formaat, bijvoorbeeld: 'application/fhir+json; fhirVersion=4.0;charset=utf-8'
ETagLabel voor het gebruik van Optimistic concurrency, bijvoorbeeld: W/"2021-01-22T12:12:03.401+00:00"

Rationale

Doordat de basis voor alle (technische) interacties in Koppeltaal is gebaseerd op FHIR RESTful API, wordt Koppeltaal hierdoor vereenvoudigd en de zichtbaarheid van interacties wordt verbeterd door een algemene interface toe te passen.

Implicaties


Voorbeelden

Representatie

Voorbeeld JSON

JSON Patient
{
	"resourceType": "Patient",
	"contact":  [
		{
    		"name": {
                "text":"\"Iñtërnâtiônàlizætiøn\u0022"
            }
		}
	]
}

Voorbeeld XML

XML Patient
<Patient xmlns="http://hl7.org/fhir">
	<contact>
		<name>
        	<text value="&quot;I&#241;t&#235;rn&#226;ti&#244;liz&#230;ti#248;n&quot;"/>
        </name>
	</contact>
</Patient>

Toepassingsgebied

FHIR-interacties

Onderbouwen

Zie Beschrijving

Eisen


Referenties