uit:

TOP-KT-001 - Componenten, Interfaces en Diensten - [review]

Beschrijving

Koppeltaal 2.0 bestaat uit systeem componenten. In ArchiMate (een EA modelleer taal) wordt hier de term "applicatie component" gebruikt) die andere systeem componenten functies en diensten (component instanties) aanbiedt, zonder die andere systeem component te belasten met hoe dat precies gebeurt. De functies of aangeboden diensten wordt ontsloten of aangeboden via interfaces. De interfaces zijn dus de koppelvlakken tussen de verschillende systeem componenten. Bij elke interface is er sprake van een aanbieder die volgens de interface specificaties functies of (gegevens) diensten aanbiedt aan afnemers.

Overwegingen

In de doelstelling van stichting Koppeltaal is middels het woord ‘interne’ een beperking voor de interfaces en de daarbij behorende Koppeltaal diensten opgenomen. Met deze beperking wordt bedoeld dat de interfaces aangeboden worden onder de verantwoordelijkheid van één zorgaanbieder (domein). De dienstverlenende componenten worden geleverd door verschillende leveranciers. Deze leveranciers kunnen hun componenten ontsluiten via het Koppeltaal platform onder de verantwoordelijkheid van de zorgaanbieder (domein).

Toepassing en restricties

Specifiek voor Koppeltaal:

Koppeltaal 2.0 bestaat uit de volgende systeem componenten en collaboraties:

"Koppeltaal voorziening" : Alle producten, functies en diensten die nodig zijn om de informatiestromen tussen (zorg) toepassingen op een veilige manier tot stand te brengen in de context van "Blended Care" (combinatie tussen traditionele therapie en digitale therapie/interventies)
"Koppeltaal domein": Het geheel van samenwerking tussen de Koppeltaal voorziening en Koppeltaal platform onder de verantwoordelijkheid van een zorgaanbieder.
"Koppeltaal platform" : Een platform geeft toegang tot een palet aan gestandaardiseerde informatiesystemen en technologie. Het platform kan gebruik maken van, of diensten verlenen aan een applicatie of eHealth module.
"Portaal" : Een toegangspoort of -(verzamel)punt tot informatie over een bepaald onderwerp die een gebruiker een uniforme toegang biedt naar achterliggende systeem componenten. Het kan ook worden beschouwd als een bibliotheek met gepersonaliseerde en gecategoriseerde inhoud voor een groep personen die toegang krijgen tot functionaliteiten over of het gebruik van activiteiten. Een portaal handelt HTTP berichten af.
"Client Applicatie": Is een zelfstandig (software) programma module die rechtstreeks met de gebruikers communiceert en gebruik maakt van de Koppeltaal voorziening om met andere eHealth modules gegevens uit te kunnen wisselen, in het zorgproces.
"eHealth Module": Software dat een eHealth toepassing is, dat aangeboden wordt aan cliënten zonder tussenkomst van behandelaren, met als doel de gezondheid van de cliënten te ondersteunen en te verbeteren.
"Bevoegdheden": Het component dat bevoegdheden aan concrete component instanties (diensten) toekent en het verklaren daarvan, tot aan het intrekken (verwijderen) van bevoegdheden.
"Toegangscontrole": Systeem component dat besluit of een concreet component instantie toegang krijgt tot de FHIR Resource Provider. Gebaseerd op het OAuth 2.0 autorisatie raamwerk (RFC6749).
"Identiteit & Authenticatie": Systeem component dat de identiteit van concrete component instanties (diensten) tot stand brengt (en onderhoud en actualiseert) met de daarbij behorende authenticatie middelen.
"FHIR Resource Provider": Systeem component die de benodigde gegevens afschermt en reageert op verzoeken om gegevens beschikbaar te stellen en te bewaren met gebruikmaking van toegangstokens.
"Logging": Systeem component die alle uitvoerende handelingen vastlegt, zoals bedoeld in de AVG (Algemene Verordening Gegevensbescherming) en NEN7513:2018. Daarnaast wordt er functionaliteit aangeboden om de geregistreerde handelingen te kunnen opvragen.

De Koppeltaal 2.0 Interfaces:

"FHIR REST API" : Worden gegevens op een consistente manier uitgewisseld op basis van de HL7 FHIR R4 - specificaties.
"OAuth2" : Een Open Autorisatie protocol dat gebruikt wordt om toegang te krijgen tot beveiligde resources via (FHIR) REST API's.
"AppRegistratie": Worden gegevens van een concrete component instantie op een consistente en veilige manier vastgelegd.
"LogEntry" : Het vastleggen van een FHIR REST API interactie (tussen de systeem componenten) in een logregel.
"Subscription Channel": Een abonnementskanaal voor het versturen van notificaties door de FHIR Resource Provider bij bepaalde gebeurtenissen. De systeem componenten kunnen zelf de gebeurtenis (criteria) aangeven waarin zij geïnteresseerd zijn.

Het beheer van de Koppeltaal voorzieningen gebeurt via de dienst:

"Beheerdersportaal": Is een beveiligde online omgeving waarin beheerders (technische) configuraties voor Koppeltaal kunnen doorvoeren en beheren, zoals identiteiten, authenticatie middelen en bevoegdheden.

Opmerking: De Koppeltaal 2.0 diensten, zoals hierboven beschreven, kunnen afwijken of gecombineerd worden. De mogelijkheden (rol beschrijving) van een dienst wordt in een Autorisatie matrix vastgelegd en zijn meestal gebaseerd op het "need-to-know" principe.

Voorbeelden

Toepassingsgebied

Koppeltaal domein

Onderbouwen

FHIR RESTful API's en SMART on FHIR

We hebben te maken met verschillende (onafhankelijke) ICT leveranciers waarmee we samen een Koppeltaal stelsel willen ontwikkelen. De functionaliteit van deze systeem componenten worden beschikbaar gesteld middels FHIR RESTful API’s (zie basis interacties) en SMART on FHIR, een op standaarden gebaseerd applicatie platform om (medische) informatie uit te wisselen op een eenduidige, veilige en betrouwbare manier.

De ontwikkelaars van bijvoorbeeld de verschillende zorgtoepassingen integreren functionaliteit van een groot aantal systeem componenten met behulp van deze FHIR REST API’s en SMART on FHIR specificaties. Om de integratie inspanning zo laag mogelijk te houden, dient de leercurve van de FHIR RESTful API’s zo kort mogelijk te zijn. Dit wordt o.a. bereikt door een goed FHIR RESTful API-ontwerp, herkenbaarheid over de FHIR RESTful API’s heen, toepassen van de-facto standaarden en goede documentatie.

Dit vereist dat de FHIR RESTful API ’s op een uniforme manier zijn opgezet en bruikbaar zijn, en goed gedocumenteerd zijn. Met OpenAPI Specification (OAS) kunnen we de eigenschappen beschrijven van de data die een API als input accepteert en als output teruggeeft. OAS 3.0 specificeert alleen welke attributen de API verwerkt en hun datatypen, niet welke implementatie er achter de API schuilgaat. OAS 3.0 is dus een beschrijvende taal en heeft geen binding met specifieke programmeertalen. Een specificatie conform OAS 3.0 is een tekstbestand met een gestandaardiseerde YAML of JSON structuur.

De volgende basis eisen stellen we aan de FHIR RESTful API’s

Maak gebruik van web, SMART on FHIR en beveiliging standaarden (zie toegangsbeheersing)
Gebruiksvriendelijk voor ontwikkelaars (zie de basis interacties)
Eenvoudig en consistent in gebruik (zie de basis interacties)
Kanaal onafhankelijk en flexibel (Koppeltaal is gebaseerd op de FHIR RESTful API's en SMART on FHIR)

SMART on FHIR definieert een workflow die een toepassing kan gebruiken om veilig toegang tot gegevens aan te vragen en die gegevens vervolgens te ontvangen en te gebruiken.

Bovenstaande beschreven strategie gaat uit van een FHIR RESTful API-first aanpak. Dit betekent dat de FHIR RESTful API ontworpen en gebouwd wordt, onafhankelijk van de applicaties waarin deze gebruikt wordt.

De FHIR RESTful APIs is een product op zichzelf. Een API moet elk kanaal kunnen bedienen en niet één specifiek kanaal. Dit wil niet zeggen dat de FHIR RESTful API los van de werkelijkheid wordt ontwikkeld. Er wordt nauw afgestemd met verschillende partijen, en hun input wordt gebruikt bij het ontwikkelen, beheren en onderhouden van de FHIR RESTful APIs.

Een FHIR RESTful API is een combinatie van het koppelvlak, documentatie en andere ondersteunende hulpmiddelen, zoals de registratie, autorisatie en logging van de systeem componenten.