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.

Eisen

CID - Eisen (en aanbevelingen) voor Componenten, Interfaces, en Diensten

Links naar gerelateerde onderwerpen

FHIR RESTful API's (volgens HL7 FHIR R4 specificatie)

SMART on FHIR: https://docs.smarthealthit.org/

OAS 3.0: https://spec.openapis.org/oas/v3.1.0

OAuth2: https://oauth.net/2/; Rfc 6749: https://www.rfc-editor.org/rfc/rfc6749

TOP-KT-009

Oude tekst

In onderstaande tabel zijn de verplichte velden van de FHIR resources R4 opgenomen, aangevuld met de functioneel verplichte velden binnen Koppeltaal 2.0 en optionele velden binnen Koppeltaal 2.0.

Deze lijst is samengesteld op basis van Architectuur besluit AB.XII (AB.XII - Attributen en dialecten) en betreft de resources voorzien van oranje header. Binnen Koppeltaal is afgesproken alleen van deze velden gebruik te maken.

De CapabilityStatement, Bundle en OperationOutcome zijn niet opgenomen in de tabel, omdat deze resource niet in de FHIR Store worden opgenomen.

Koppeltaal 2.0 profielen

Van bovenstaande FHIR resources zijn Koppeltaal 2.0 profielen aangemaakt en gepubliceerd in https://simplifier.net/Koppeltaalv2.0.

Deze worden als basis gebruikt voor Koppeltaal 2.0.

Meta					Elke FHIR R4 Resource bevat een "meta" element van het type Meta wat een set metadata is die technische content meegeeft aan de resource. Binnen de context van Koppeltaal zullen we gebruik maken van enkele elementen uit de metadata set.
FHIR R4 Resource	Element	Type	Verplicht in KT 2.0 (profile)	Functioneel nodig in KT 2.0	Omschrijving en reden
	versionId	id	X		De waarde van versionId verandert elke keer als de inhoud van de resource verandert. Er kan naar worden verwezen in een resource referentie (voorbeeld: ResourceType/id/_history/versionId). Dit veld wordt door FHIR Resource Provider bijgehouden.
	lastUpdated	instant	X		Dit element verandert de waarde als de content van de resource verandert.
	source	uri	X		Een samengestelde string die het resource systeem en interactie (bv create, update, etc) uniek identificeert. In de context van Koppeltaal wordt voor het resource systeem het "applicatie of client id" gebruikt. Voorbeeld: `"source": "urn:uuid:client_id#interaction_id"`
	profile	canonical(StructureDefinition)			Een bewering of toekenning dat de inhoud van de resource overeenkomt met een resource profile (vastgelegd in een StructureDefinition). Zie FHIR Profiles voor verdere uitleg. Een profile wordt gewijzigd als de waardensets wijzigen of het systeem de conformiteit opnieuw controleert. De profile kan worden gebruikt om aan te geven aan welke versie(s) de FHIR resource moet voldoen.
Patient					De persoon die in behandeling is bij de zorgaanbieder.
	identifier	Identifier	X..*		Elke patiënt moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen. Er mogen meerdere type identifiers gebruikt worden
	active	boolean	X		Of de patiënt actief is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	name	HumanName		X..*	Eén of meerdere namen die aan de patiënt wordt geassocieerd.
	name.nameInformation.use	code	X		Fixed value: Official
	name.nameInformation .family	string		X	Achternaam
	name.nameInformation.given	string		X..*	Voorna(a)m(en)
	telecom	ContactPoint			De contactdetails (telefoonnummers, emailadressen)van de patiënt.
	gender	code		X	Het geslacht van de patiënt. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html
	birthDate	date		X	Geboorte datum van de patiënt.
	adress	nl core AddressInformation			Adres van de patient (straat, huisnummer, woonplaats, postcode, land)
	managingOrganization	Reference
Practitioner					De zorgverlener die in overleg met de patiënt een eHealth activiteit toewijst.
	identifier	Identifier	X..*		Elke behandelaar moet uniek te identificeren zijn a.d.h.v. identifiers, zodat we altijd de gegevens kunnen opvragen.
	active	boolean	X		Of de behandelaar actief is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	name	HumanName		X..*	De naam die aan de behandelaar wordt geassocieerd.
	telecom	ContactPoint		X	Contact details van de behandelaar. (email adres is verplicht, telefoonnummer optioneel)
	gender	code			Het geslacht van de behandelaar. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html.
	birthDate	date			Geboortedatum van de behandelaar
RelatedPerson	(Voorlopig out of scope)				Naaste van de patiënt die betrokken is in het behandelproces. (voorlopig out of scope)
	identifier	Identifier	X..*		Elke naaste moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen.
	active	boolean	X		Of de naaste persoon actief betrokken is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	patient	Reference(Patient)			Uit FHIR R4. De patiënt waarmee deze persoon een relatie mee heeft.
	telecom	ContactPoint			Contactdetails van deze persoon.
	birthDate	date	X		Geboortedatum van deze persoon.
	address	Address			Adres waar deze persoon bereikt kan worden (straat, huisnummer, woonplaats, postcode, land).
	name	HumanName		X..*	De naam die aan deze persoon wordt geassocieerd.
	name.nameInformation.use	code	X		Fixed value: Official
	name.nameInformation.family	string		X	Achternaam
	name.nameInformation.given	string		X..*	Voorna(a)m(en)
	gender	code		X	Het geslacht van deze persoon. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html
Task					De aan een patiënt toegewezen eHealth activiteit.
	identifier	Identifier	X..*		Identificatie van een activiteit
	description	string			Leesbare uitleg van taakomschrijving
	code	CodeableConcept			Taaktype
	instantiatesCanonical	canonical(ActivityDefinition)	X		Een referentie naar een beschrijving van een eHealth activiteit moet bij het opvoeren van een taak In de context van Koppeltaal altijd gevuld worden.
	status	code	X		In de context van Koppeltaal moet altijd de status van een eHealth activiteit bekend zijn. Initieel wordt de taak op 'ready' gezet om aan te geven dat de taak toegewezen en geaccepteerd is. Zie https://www.hl7.org/fhir/valueset-task-status.html.
	intent	code	X		Uit FHIR R4. De intentie vertegenwoordigt een 'order' tot een eHealth activiteit en autorisatie voor uitvoering van de taak door een participant. Zie http://hl7.org/fhir/R4/codesystem-request-intent.html.
	requester	Reference(Practitioner)			In Koppeltaal wordt dit veld uitgevoerd met een referentie naar de aanvrager van de eHealth activiteit.
	owner	Reference(Patient)	X		Een verplichte referentie naar de patiënt die verantwoordelijk is voor de uitvoering van de toegewezen eHealth activiteit.
	restriction.recipient	Reference(Practitioner)			Wordt in Koppeltaal gebruikt voor het koppelen van betrokkenen aan de eHealth activiteit.
	restriction.period	Period			Taak periode (beperking)
	for	Reference(Patient)			Bevat een referentie naar voor wie we het doen of wie er baat bij heeft. Bij Koppeltaal is dit de Patient.
	authoredOn	dateTime			Creatie datum van de eHealth activiteit.
	lastModified	dateTime			Datum waarop laatste wijziging is doorgevoerd op de eHealth activiteit.
ActivityDefinition					Beschrijving van een eHealth activiteit.
	ext: publisherIdentifier	id	X		Verplichte identificatie van de uitgever van de eHealth activiteit.
	ext: endpoint	Reference(Endpoint)	X..*		Verplichte referentie naar de dienstverlenende applicatie (endpoint) die de eHealth activiteit levert. Kunnen er meerdere van zijn
	version	string			Bedrijfsversie van deze eHealth activiteit.
	url	uri	X		Een herkenbare identifier voor deze eHealth activiteit dat als een URI gepresenteerd wordt.
	identifier	Identifier			Een extra (globale) identificatie element voor het kunnen identificeren van een eHealth activiteit.
	name	string			De naam van de eHealth activiteit.
	title	string	X		Dit titel van de eHealth activiteit wordt (verplicht) getoond aan gebruikers en moet gevuld worden. Nodig voor het kunnen toewijzen van een eHealth activiteit.
	subtitle	string			Ondergeschikte titel van de ehealth activiteit.typexxxxx
	status	code	X		Uit FHIR R4. Zodra de eHealth activiteit gepubliceerd wordt, wordt deze op 'active' gezet. Indien de activiteit NIET meer gebruikt wordt, wordt deze op 'retired' gezet. Zie: http://hl7.org/fhir/publication-status
	subject	SubjectReference			Onderwerp
	description	markdown			Een omschrijving van de eHealth activiteit.
Endpoint					Een eHealth (eind)punt is een technische representatie van een adres of Uniform Resource Locator (URL) van een applicatie instantie die eHealth of FHIR REST diensten aanbiedt.
	identifier	Identifier			Unieke endpoint identifier.
	status	code	X		Uit FHIR R4. De status van een endpoint. Standaard wordt deze op 'active' gezet. Andere mogelijke modes zijn beschreven in https://www.hl7.org/fhir/valueset-endpoint-status.html
	name	string			Naam waarmee het endpoint geïdentificeerd kan worden.
	address	url	X		Uit FHIR R4. Het technische basis adres waarmee de verbinding wordt opgezet.
	connectionType	Coding	X		Uit FHIR R4. Het protocol wat gebruikt wordt bij dit endpoint. Standaard voor Koppeltaal op 'hl7-fhir-rest' zetten. Zie ook: https://www.hl7.org/fhir/valueset-endpoint-connection-type.html.
	payloadType	CodeableConcept	X		Uit FHIR R4. Type inhoud wat gebruikt wordt voor dit endpoint. Zie ook: https://www.hl7.org/fhir/valueset-endpoint-payload-type.html.
Device					Een (gefabriceerde) applicatie instantie (in Koppeltaal terminologie) dat gebruikt wordt ter ondersteuning of het verlenen van gezondheidszorg.
	identifier	Identifier	X		Instantie identifier van het product. Is de client id
	status	code	X		De status van het product
	type	CodeableConcept			Soort/type product. Zie: http://hl7.org/fhir/ValueSet/device-type
	url	uri			Netwerk adres om applicatie te bereiken
	specialization	BackboneElement			Mogelijkheden van product
	deviceName.name	string	X		Naam van het product
	deviceName.type	code	X		Standaard waarde: user-friendly-name
Subscription					Een abonnement wordt gebruikt om geïnformeerd te worden over wijzigingen op (resource) gegevens door andere systemen. Nadat een abonnement is geregistreerd en wijzigingen op (resource) gegevens voorkomen die overeen komen met een vastgelegde criteria, verzendt deze een bericht (notificatie) op een voor gedefinieerde "kanaal", zodat een ander systeem hierop actie kan ondernemen.
	status	code	X		Uit FHIR R4. Status van het abonnement. Zie: http://hl7.org/fhir/subscription-status.
	criteria	string	X		Uit FHIR R4. De vastgelegde criteria waarop er een bericht (notificatie) wordt verstuurd.
	reason	string	X		Uit FHIR R4. Omschrijving waarom dit abonnement is gecreëerd.
	channel	BackboneElement	X		Uit FHIR R4. Voor gedefinieerd kanaal waar het bericht wordt verstuurd.
	channel.type	code	X		Uit FHIR R4. Ondersteunen alleen: "rest-hook" kanaal.
	channel.endpoint	url	X?		Omdat we rest-hook als kanaaltype verplichten, moet ook het endpoint vastgelegd worden. Endpoint zou niet raadbaar moeten zijn en uniek per subscription.
	channel.header	string	X?		Om DOS aanvallen te voorkomen, wordt een "Authorization" header verplicht (voor afgesproken token meesturen). Men kan ook de vastgelegde criteria in de header vastleggen.
	channel.payload	code	XXX (NIET)		Dit veld MOET NIET gebruikt worden. De notificaties worden zonder payload verstuurd. Extra informatie over een notificatie kan via de channel.header meegegeven worden.
CareTeam					Beschrijft het zorgteam met de participanten.
	identifier	Identifier	X		Elke zorgteam moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen.
	status	code	X		In de context van Koppeltaal moet altijd de status van het zorgteam bekend zijn.
	subject	Reference(Patient)	X		Uit FHIR R4. Voor wie het team aan de slag is. In de context van Koppeltaal is dit een referentie naar Patient.
	period	Period			Tijdsperiode van het zorgteam.
	participant	BackboneElement			Lijst van betrokken participanten bij het zorgproces
	participant.role	CodeableConcept	x		Uit FHIR R4. Verplichte rol van de participant, bij toevoeging van participant.
	participant.member	Reference (Practitioner\|RelatedPerson)	x		Uit FHIR R4. Verplichte type participant, bij toevoeging van participant.
AuditEvent					Een logrecord van een interactie tussen systemen. Koppeltaal Logging moet het mogelijk maken "achteraf onweerlegbaar vast te stellen welke activiteiten waar en wanneer hebben plaatsgevonden.
	type	Coding	X		Soort gebeurtenis. Zie "system": http://terminology.hl7.org/CodeSystem/audit-event-type. Standaard "code": "rest" Bij het lanceren van applicaties wordt het: "system":"http://dicom.nema.org/resources/ontology/DCM", "code":"110100", "display":"Application Activity"
	subtype	Coding	X?		Gedetailleerde beschrijving van FHIR gebeurtenis. Zie system: http://hl7.org/fhir/restful-interaction Bij het lanceren van applicaties gebruiken we: "system":"http://dicom.nema.org/resources/ontology/DCM", "code":"110120", "display":"Application Start"
	action	code			Welke CRUDE acties is uitgevoerd. Zie: http://hl7.org/fhir/audit-event-action
	recorded	instant	X		Tijdstip van logmoment.
	agent.who	Reference(Device)	X?		De device actor (audit participant) van de zendende of ontvangende partij.
	agent.type	CodeableConcept	X?		Zie: system: http://dicom.nema.org/resources/ontology/DCM code: 110150 display: "Application" - Audit participant role ID of software application code: 110151 display: "Application Launcher" - Audit participant role ID of software application launcher, i.e., the entity that started or stopped an application code: 110152 display: "Destination Role ID" Audit participant role ID of the receiver of data code: 110153 display: "Source Role ID" Audit participant role ID of the sender of data
	agent.role	CodeableConcept			Kunnen we onze applicatie rollen hier voor gebruiken, als deze zijn vastgelegd?
	agent.requestor	boolean	X		Is de agent de initiator van de gebeurtenissen, dan 'true' anders 'false'.
	entity.type	CodeableConcept	X?		Type resource. Zie: "http://hl7.org/fhir/resource-types". Zie het KT 2.0 FHIR Resource Model.
	entity.what	Reference(Any)	X?		Over welke (FHIR) resource gaat het Reference(Any). B.v: entity.what=Patient/123
	entity.name	string			resource.identifier
	source.site	string			Naam van de omgeving (domein!)
	source.observer	Reference(Device)	X		Wie heeft het gelogd. Misschien een aparte Log Device.
	source.type	Coding			Wat voor systeem is dit. Zie: http://terminology.hl7.org/CodeSystem/security-source-type

? = in Simplifier 0..1

Beschrijving

In de doelstelling van stichting Koppeltaal is middels het woord ‘interne’ een beperking voor de gegevensuitwisseling opgenomen. Met deze beperking wordt bedoeld dat gegevensuitwisseling altijd plaatsvindt onder de verantwoordelijkheid van één zorgaanbieder.

Gegevens worden uitgewisseld tussen verschillende dienstverlenende applicaties. In Koppeltaal staat het begrip applicaties voor alle vormen van ICT-systemen en eHealth platformen die voor een zorgaanbieder relevant zijn om gegevens tussen uit te wisselen in de context van eHealth activiteiten. De dienstverlenende applicaties worden geleverd door verschillende leveranciers. Deze leveranciers kunnen hun dienstverlenende applicaties ontsluiten via Koppeltaal onder de verantwoordelijkheid van de zorgaanbieder. Alle FHIR resources van één zorgaanbieder kunnen via de Koppeltaal (FHIR Resource) Provider ontsloten worden, voor die dienstverlenende applicaties die aangesloten zijn op Koppeltaal. Daarbij maken wij gebruik van gemeenschappelijke begrippen en standaarden die gebaseerd zijn op HL7/FHIR (https://www.hl7.org/fhir/http.html).

Het volgende diagram geeft een overzicht van de FHIR Resources (Koppeltaal basis set) en de onderlinge relaties tussen de resources voor Koppeltaal 2.0.

Alle FHIR Resources en de daarbij behorende elementen in Koppeltaal 2.0 zijn gebaseerd op FHIR Release #4 (4.0.1 2019-10-30) - http://hl7.org/fhir/R4/.

Bij daadwerkelijke uitwisseling kunnen de FHIR Resources worden weergegeven in XML en/of JSON formaten.

Nieuwe plaat:

Kleuren verwijderd omdat niemand wist wat ze voorstelden
Related person Out of Scope geplaatst.

Volgend lijstje geeft de verplichte velden weer van de FHIR resources R4, die binnen Koppeltaal 2.0 worden gebruikt.

Dit lijstje is door VZVZ samengesteld. De CapabilityStatement, Bundle en OperationOutcome zijn niet opgenomen in dit lijstje, omdat deze resource niet in de FHIR Store worden opgenomen.

Koppeltaal 2.0 profielen

Van bovenstaande FHIR resources zijn Koppeltaal 2.0 profielen aangemaakt en gepubliceerd in https://simplifier.net/Koppeltaalv2.0.

Deze worden als basis gebruikt voor Koppeltaal 2.0.

FHIR R4 Resource	Element	Type	Verplicht in KT 2.0 (profile)	Functioneel nodig in KT 2.0	Omschrijving en reden
Meta					Elke FHIR R4 Resource bevat een "meta" element van het type Meta wat een set metadata is die technische content meegeeft aan de resource. Binnen de context van Koppeltaal zullen we gebruik maken van enkele elementen uit de metadata set.
	versionId	id	X		De waarde van versionId verandert elke keer als de inhoud van de resource verandert. Er kan naar worden verwezen in een resource referentie (voorbeeld: ResourceType/id/_history/versionId). Dit veld wordt door FHIR Resource Provider bijgehouden.
	lastUpdated	instant	X		Dit element verandert de waarde als de content van de resource verandert.
	source	uri	X		Een samengestelde string die het resource systeem en interactie (bv create, update, etc) uniek identificeert. In de context van Koppeltaal wordt voor het resource systeem het "applicatie of client id" gebruikt. Voorbeeld: `"source": "urn:uuid:client_id#interaction_id"`
	profile	canonical(StructureDefinition)			Een bewering of toekenning dat de inhoud van de resource overeenkomt met een resource profile (vastgelegd in een StructureDefinition). Zie FHIR Profiles voor verdere uitleg. Een profile wordt gewijzigd als de waardensets wijzigen of het systeem de conformiteit opnieuw controleert. De profile kan worden gebruikt om aan te geven aan welke versie(s) de FHIR resource moet voldoen.
Patient					De persoon die in behandeling is bij de zorgaanbieder.
	identifier	Identifier	X..*		Elke patiënt moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen. Er mogen meerdere type identifiers gebruikt worden
	active	boolean	X		Of de patiënt actief is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	name	HumanName		X..*	Eén of meerdere namen die aan de patiënt wordt geassocieerd.
	name.nameInformation.use	code	X		Fixed value: Official
	name.nameInformation.family	string		X	Achternaam
	name.nameInformation.given	string		X..*	Voorna(a)m(en)
	telecom	ContactPoint			De contactdetails (telefoonnummers, emailadressen)van de patiënt.
	gender	code		X	Het geslacht van de patiënt. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html
	birthDate	date		X	Geboorte datum van de patiënt.
	adress	nl core AddressInformation			Adres van de patient (straat, huisnummer, woonplaats, postcode, land)
	managingOrganization	Reference
Practitioner					De zorgverlener die in overleg met de patiënt een eHealth activiteit toewijst.
	identifier	Identifier	X..*		Elke behandelaar moet uniek te identificeren zijn a.d.h.v. identifiers, zodat we altijd de gegevens kunnen opvragen.
	active	boolean	X		Of de behandelaar actief is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	name	HumanName		X..*	De naam die aan de behandelaar wordt geassocieerd.
	telecom	ContactPoint		X	Contact details van de behandelaar. (email adres is verplicht, telefoonnummer optioneel)
	gender	code			Het geslacht van de behandelaar. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html.
	birthDate	date			Geboortedatum van de behandelaar
RelatedPerson	Voorlopig out of scope)				Naaste van de patiënt die betrokken is in het behandelproces. (voorlopig out of scope)
	identifier	Identifier	X..*		Elke naaste moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen.
	active	boolean	X		Of de naaste persoon actief betrokken is, binnen de Koppeltaal context. Initieel op 'true' zetten.
	patient	Reference(Patient)			Uit FHIR R4. De patiënt waarmee deze persoon een relatie mee heeft.
	telecom	ContactPoint			Contactdetails van deze persoon.
	birthDate	date	X		Geboortedatum van deze persoon.
	address	Address			Adres waar deze persoon bereikt kan worden (straat, huisnummer, woonplaats, postcode, land).
	name	HumanName		X..*	De naam die aan deze persoon wordt geassocieerd.
	name.nameInformation.use	code	X		Fixed value: Official
	name.nameInformation.family	string		X	Achternaam
	name.nameInformation.given	string		X..*	Voorna(a)m(en)
	gender	code		X	Het geslacht van deze persoon. Zie https://www.hl7.org/fhir/valueset-administrative-gender.html
Task					De aan een patiënt toegewezen eHealth activiteit.
	identifier	Identifier	X..*		Identificatie van een activiteit
	description	string			Leesbare uitleg van taakomschrijving
	code	CodeableConcept			Taaktype
	instantiatesCanonical	canonical(ActivityDefinition)	X		Een referentie naar een beschrijving van een eHealth activiteit moet bij het opvoeren van een taak In de context van Koppeltaal altijd gevuld worden.
	status	code	X		In de context van Koppeltaal moet altijd de status van een eHealth activiteit bekend zijn. Initieel wordt de taak op 'ready' gezet om aan te geven dat de taak toegewezen en geaccepteerd is. Zie https://www.hl7.org/fhir/valueset-task-status.html.
	intent	code	X		Uit FHIR R4. De intentie vertegenwoordigt een 'order' tot een eHealth activiteit en autorisatie voor uitvoering van de taak door een participant. Zie http://hl7.org/fhir/R4/codesystem-request-intent.html.
	requester	Reference(Practitioner)			In Koppeltaal wordt dit veld uitgevoerd met een referentie naar de aanvrager van de eHealth activiteit.
	owner	Reference(Patient)	X		Een verplichte referentie naar de patiënt die verantwoordelijk is voor de uitvoering van de toegewezen eHealth activiteit.
	restriction.recipient	Reference(Practitioner)			Wordt in Koppeltaal gebruikt voor het koppelen van betrokkenen aan de eHealth activiteit.
	restriction.period	Period			Taak periode (beperking)
	for	Reference(Patient)			Bevat een referentie naar voor wie we het doen of wie er baat bij heeft. Bij Koppeltaal is dit de Patient.
	authoredOn	dateTime			Creatie datum van de eHealth activiteit.
	lastModified	dateTime			Datum waarop laatste wijziging is doorgevoerd op de eHealth activiteit.
ActivityDefinition					Beschrijving van een eHealth activiteit.
	ext: publisherIdentifier	id	X		Verplichte identificatie van de uitgever van de eHealth activiteit.
	ext: endpoint	Reference(Endpoint)	X..*		Verplichte referentie naar de dienstverlenende applicatie (endpoint) die de eHealth activiteit levert. Kunnen er meerdere van zijn
	version	string			Bedrijfsversie van deze eHealth activiteit.
	url	uri	X		Een herkenbare identifier voor deze eHealth activiteit dat als een URI gepresenteerd wordt.
	identifier	Identifier			Een extra (globale) identificatie element voor het kunnen identificeren van een eHealth activiteit.
	name	string			De naam van de eHealth activiteit.
	title	string	X		Dit titel van de eHealth activiteit wordt (verplicht) getoond aan gebruikers en moet gevuld worden. Nodig voor het kunnen toewijzen van een eHealth activiteit.
	subtitle	string			Ondergeschikte titel van de ehealth activiteit.typexxxxx
	status	code	X		Uit FHIR R4. Zodra de eHealth activiteit gepubliceerd wordt, wordt deze op 'active' gezet. Indien de activiteit NIET meer gebruikt wordt, wordt deze op 'retired' gezet. Zie: http://hl7.org/fhir/publication-status
	subject	SubjectReference			Onderwerp
	description	markdown			Een omschrijving van de eHealth activiteit.
Endpoint					Een eHealth (eind)punt is een technische representatie van een adres of Uniform Resource Locator (URL) van een applicatie instantie die eHealth of FHIR REST diensten aanbiedt.
	identifier	Identifier			Unieke endpoint identifier.
	status	code	X		Uit FHIR R4. De status van een endpoint. Standaard wordt deze op 'active' gezet. Andere mogelijke modes zijn beschreven in https://www.hl7.org/fhir/valueset-endpoint-status.html
	name	string			Naam waarmee het endpoint geïdentificeerd kan worden.
	address	url	X		Uit FHIR R4. Het technische basis adres waarmee de verbinding wordt opgezet.
	connectionType	Coding	X		Uit FHIR R4. Het protocol wat gebruikt wordt bij dit endpoint. Standaard voor Koppeltaal op 'hl7-fhir-rest' zetten. Zie ook: https://www.hl7.org/fhir/valueset-endpoint-connection-type.html.
	payloadType	CodeableConcept	X		Uit FHIR R4. Type inhoud wat gebruikt wordt voor dit endpoint. Zie ook: https://www.hl7.org/fhir/valueset-endpoint-payload-type.html.
Device					Een (gefabriceerde) applicatie instantie (in Koppeltaal terminologie) dat gebruikt wordt ter ondersteuning of het verlenen van gezondheidszorg.
	identifier	Identifier	X		Instantie identifier van het product. Is de client id
	status	code	X		De status van het product
	type	CodeableConcept			Soort/type product. Zie: http://hl7.org/fhir/ValueSet/device-type
	url	uri			Netwerk adres om applicatie te bereiken
	specialization	BackboneElement			Mogelijkheden van product
	deviceName.name	string	X		Naam van het product
	deviceName.type	code	X		Standaard waarde: user-friendly-name
Subscription					Een abonnement wordt gebruikt om geïnformeerd te worden over wijzigingen op (resource) gegevens door andere systemen. Nadat een abonnement is geregistreerd en wijzigingen op (resource) gegevens voorkomen die overeen komen met een vastgelegde criteria, verzendt deze een bericht (notificatie) op een voor gedefinieerde "kanaal", zodat een ander systeem hierop actie kan ondernemen.
	status	code	X		Uit FHIR R4. Status van het abonnement. Zie: http://hl7.org/fhir/subscription-status.
	criteria	string	X		Uit FHIR R4. De vastgelegde criteria waarop er een bericht (notificatie) wordt verstuurd.
	reason	string	X		Uit FHIR R4. Omschrijving waarom dit abonnement is gecreëerd.
	channel	BackboneElement	X		Uit FHIR R4. Voor gedefinieerd kanaal waar het bericht wordt verstuurd.
	channel.type	code	X		Uit FHIR R4. Ondersteunen alleen: "rest-hook" kanaal.
	channel.endpoint	url	X?		Omdat we rest-hook als kanaaltype verplichten, moet ook het endpoint vastgelegd worden. Endpoint zou niet raadbaar moeten zijn en uniek per subscription.
	channel.header	string	X?		Om DOS aanvallen te voorkomen, wordt een "Authorization" header verplicht (voor afgesproken token meesturen). Men kan ook de vastgelegde criteria in de header vastleggen.
	channel.payload	code	XXX (NIET)		Dit veld MOET NIET gebruikt worden. De notificaties worden zonder payload verstuurd. Extra informatie over een notificatie kan via de channel.header meegegeven worden.
CareTeam					Beschrijft het zorgteam met de participanten.
	identifier	Identifier	X		Elke zorgteam moet uniek te identificeren zijn a.d.h.v. een identifier, zodat we altijd de gegevens kunnen opvragen.
	status	code	X		In de context van Koppeltaal moet altijd de status van het zorgteam bekend zijn.
	subject	Reference(Patient)	X		Uit FHIR R4. Voor wie het team aan de slag is. In de context van Koppeltaal is dit een referentie naar Patient.
	period	Period			Tijdsperiode van het zorgteam.
	participant	BackboneElement			Lijst van betrokken participanten bij het zorgproces
	participant.role	CodeableConcept	x		Uit FHIR R4. Verplichte rol van de participant, bij toevoeging van participant.
	participant.member	Reference(Practitioner\|RelatedPerson)	x		Uit FHIR R4. Verplichte type participant, bij toevoeging van participant.
AuditEvent					Een logrecord van een interactie tussen systemen. Koppeltaal Logging moet het mogelijk maken "achteraf onweerlegbaar vast te stellen welke activiteiten waar en wanneer hebben plaatsgevonden.
	type	Coding	X		Soort gebeurtenis. Zie "system": http://terminology.hl7.org/CodeSystem/audit-event-type. Standaard "code": "rest" Bij het lanceren van applicaties wordt het: "system":"http://dicom.nema.org/resources/ontology/DCM", "code":"110100", "display":"Application Activity"
	subtype	Coding	X?		Gedetailleerde beschrijving van FHIR gebeurtenis. Zie system: http://hl7.org/fhir/restful-interaction Bij het lanceren van applicaties gebruiken we: "system":"http://dicom.nema.org/resources/ontology/DCM", "code":"110120", "display":"Application Start"
	action	code			Welke CRUDE acties is uitgevoerd. Zie: http://hl7.org/fhir/audit-event-action
	recorded	instant	X		Tijdstip van logmoment.
	agent.who	Reference(Device)	X?		De device actor (audit participant) van de zendende of ontvangende partij.
	agent.type	CodeableConcept	X?		Zie: system: http://dicom.nema.org/resources/ontology/DCM code: 110150 display: "Application" - Audit participant role ID of software application code: 110151 display: "Application Launcher" - Audit participant role ID of software application launcher, i.e., the entity that started or stopped an application code: 110152 display: "Destination Role ID" Audit participant role ID of the receiver of data code: 110153 display: "Source Role ID" Audit participant role ID of the sender of data
	agent.role	CodeableConcept			Kunnen we onze applicatie rollen hier voor gebruiken, als deze zijn vastgelegd?
	agent.requestor	boolean	X		Is de agent de initiator van de gebeurtenissen, dan 'true' anders 'false'.
	entity.type	CodeableConcept	X?		Type resource. Zie: "http://hl7.org/fhir/resource-types". Zie het KT 2.0 FHIR Resource Model.
	entity.what	Reference(Any)	X?		Over welke (FHIR) resource gaat het Reference(Any). B.v: entity.what=Patient/123
	entity.name	string			resource.identifier
	source.site	string			Naam van de omgeving (domein!)
	source.observer	Reference(Device)	X		Wie heeft het gelogd. Misschien een aparte Log Device.
	source.type	Coding			Wat voor systeem is dit. Zie: http://terminology.hl7.org/CodeSystem/security-source-type

? = in Simplifier 0..1

Rationale

FHIR Resources zijn in de basis generiek en worden met behulp van profielen uitgebreid en specifieker gemaakt voor specifieke toepassingen, zoals Koppeltaal. In Koppeltaal worden FHIR resources toegepast om gegevens uit te wisselen. In Koppeltaal zijn de gegevens die worden uitgewisseld beperkt tot de afspraak. Binnen deze afspraak ligt vast welke gegevens uitgewisseld moeten worden en wat dit voor alle applicaties in het domein betekend. Dit vormt zogenaamd de "maximale gegevensset". Het is in Koppeltaal expliciet niet toegestaan meer gegevens dan zijn afgesproken uit te wisselen. Dit omdat door het uitwisselen van gegevens impliciet bepaald gedrag verwacht wordt, en in dat geval moeten alle partijen in het domein hier mee overweg kunnen. Een goed voorbeeld om dit idee toe te lichtten is de deceased waarde in de patient. Indien deze gevuld zou worden, wordt van de gekoppelde systemen in het domein bepaald gedrag verwacht. Zonder over dit gedrag afspraken te maken, is het niet de bedoeling van dit veld gebruikt te maken. De koppeltaal FHIR resources kunnen gezien worden als een koppelvlak, en niet als een resource service of database.

Implicaties

Voorbeelden

Toepassingsgebied

Onderbouwen

Eisen

Referenties

TOP-KT-018

Oude tekst

Beschrijving

OPMERKING:

Deze pagina is niet officieel gereviewd.

Indien we met één enkele endpoint voor onze Koppeltaal dienst meerdere tenants (letterlijk: huurders) willen ondersteunen, kunnen we de FHIR Resource Provider voorzien van of uitbreiden met multitenancy.

Had een vraag uitgezet bij de FHIR Community:

Zou het handig zijn om het DomainResource uit te breiden (exentsion) met een 'tenant' element/veld van het type id, zodat elke zijn eigen FHIR resources, configuratie en beheer kan uitvoeren ?

Antwoord wat ik onder ander kreeg was het volgende:

Elke resource heeft een meta.source-element dat de herkomst van de resource kan opslaan. Er is ook een herkomstbron (Provenance resource) beschikbaar. Maar hoe wijst men de 'tenant' toe als ze allemaal in één URL samenkomen? Zonder de vereisten te kennen, is het flexibeler om voor elke tenant verschillende URL's van de basis URL af te splitsen. Die kunnen allemaal naar een enkele interne server leiden (of niet), maar het geeft opties om beleid per tenant te configureren, de gegevens via proxyservices te laten lopen om de tenants te taggen.

Bij de HAPI server kan men extra logica in de URL toevoegen (URL gebaseerde Multitenancy), om de tenant-id te bepalen, die door de aanvrager verstrekt wordt. Dit is handig bijvoorbeeld bij het ondersteunen van meerdere domeinen die op dezelfde infrastructuur gehost wordt.

Voorbeeld:

De FHIR Resource provider is bereikbaar op:
http://test.vzvz.nl/R4

Een klant wil toegang krijgen tot patient '123' in domein (tenant) 'XYZ'

Dan wordt de (multitenancy) URL:
http://test.vzvz.nl/R4/XYZ/Patient/123

Een andere manier is om de tenant-id als (encoded of http header) parameter in de aanvraag mee te sturen. Hierbij gebruikt men dus altijd één basis URL.
Voorbeeld:
http://test.vzvz.nl/R4/Patient/123?tenantId=XYZ

of HTTP Header
http://test.vzvz.nl/R4/Patient/123
X-Tenant-ID:XYZ

Men kan ook automatisch tenant selectie doen, gebaseerd op de authenticatie van applicaties (id en secret) in een bepaald domein.
Elke applicatie krijgt in een specifiek domein bepaalde credentials. Na authenticatie krijgt een applicatie bepaalde rechten (autorisatie) op basis van een tenant_id

De FHIR Resource provider moet a.d.h.v. het toegangstoken (waarin de tenant dan staat) de resources beheren.

Dit kan men m.b.v. een Autorisatie Interceptor ingeregeld worden. Hiermee kan men elke tenant een speciaal deel van de applicatie aanbieden met inbegrip van data.

Rationale

Met een multitenant architectuur, is de software applicatie ontworpen om elke tenant een speciaal deel van de applicatie te bieden - met inbegrip van data, configuratie, beheer van de gebruikers, de individuele functionaliteit van de tenant en niet-functionele eigenschappen.

Implicaties

Voorbeelden

Toepassingsgebied

Onderbouwen

Voordelen van een multitenant systeem is:

Kosten. Met resource pooling, zijn er aanzienlijke besparingen mogelijk op hardware en energie verbruik.
Schaalbaarheid. Een multitenant systeem is schaalbaar, zonder vooraf te hoeven berekenen, welke middelen er moeten worden toegevoegd, tegen welke kosten en welk termijn.
Upgrades eenvoudiger. Eenmalige update op een multitenant omgeving. Pas hierbij op dat een update alle tenants beïnvloedt.

Eisen

Referenties

TOP-KT-016

Oude tekst:

Beschrijving

De App Launch specificaties van SMART on FHIR kan worden beschreven als een set van mogelijkheden en een bepaalde 'SMART on FHIR' server implementatie kan van deze specificaties een subset implementeren.

Methoden voor het declareren van een autorisatie endpoint en andere mogelijkheden van de aan te bieden diensten door Koppeltaal worden verder beschreven op deze pagina.

SMART on FHIR OAuth autorisatie endpoints en Capabilities

De server MOET de FHIR OAuth-autorisatie endpoints en eventuele optionele SMART-mogelijkheden die hij ondersteunt overbrengen met behulp van een Well-Known Uniform Resource Identifiers (URI's) JSON-bestand.

In eerdere versies van SMART werden sommige van deze details ook overgebracht via de CapabilityStatement van een FHIR server. Dit mechanisme is volgens SMART nu verouderd.

Capability Set

Een Capability Set combineert individuele mogelijkheden om een specifieke use-case mogelijk te maken. Een SMART on FHIR-server MOET een of meer Capability Sets ondersteunen.

Tenzij anders vermeld, is elke vermelde capaciteit vereist om te voldoen aan een capaciteiten set. Elke individuele SMART-server zal een gedetailleerde lijst van zijn mogelijkheden publiceren; uit deze lijst kan een klant bepalen welke van deze Capability Sets worden ondersteund.

Capabilities

Om interoperabiliteit te bevorderen, zijn de volgende SMART on FHIR-mogelijkheden gedefinieerd. Een bepaalde set van deze mogelijkheden wordt gecombineerd ter ondersteuning van een specifiek gebruik, een Capability Set.

Launch Modes

Capability	Type	Omschrijving
Launch mode
	launch-ehr
	launch-standalone	Wordt nu niet binnen Koppeltaal gebruikt
Autorisatie methode
	authorize-post
Client type
	client-public
	client-confidential-symmetric
	client-confidential-asymmetric	Deze wordt binnen
Single Sign-On
	sso-openid-connect
Launch Context
	context-****
Permissions

De autorisatie endpoints die door een FHIR-bronserver worden geaccepteerd, worden weergegeven als een Well-Known Uniform Resource Identifiers (URI's) (RFC5785) JSON-document.

FHIR-endpoints die autorisatie vereisen, MOETEN een JSON-document weergeven op de locatie die wordt gevormd door /.well-known/smart-configuration toe te voegen aan hun basis-URL. In tegenstelling tot bijlage B.4 van RFC5785 kan de .well-known path-component worden toegevoegd, zelfs als het FHIR-eindpunt al een path-component bevat.

Antwoorden voor /.well-known/smart-configuration-verzoeken ZULLEN JSON zijn, ongeacht de Accept-headers die in het verzoek zijn opgegeven.

client applicaties KUNNEN een Accept-header weglaten
servers KUNNEN alle door de client geleverde Kopteksten accepteren
servers ZULLEN reageren met application/json

Opvragen van SMART major versie 2 configuratie per domein (zorgafnemer). Basis URL "fhir.koppeltaal.nl/domeinzorgafnemer/v2"

GET domeinzorgafnemer/v2.well-known/smart-configuration HTTP/1.1 Host: fhir.koppeltaal.nl

Response op configuratie aanvraag.

Een JSON-document moet worden geretourneerd met het type application/json mime.

meta element	verplicht	Beschrijving
issuer	conditioneel	Tekenreeks die de OpenID Connect Issuer-URL van dit systeem overbrengt. Vereist als de mogelijkheden van de server sso-openid-connect omvatten; anders weggelaten.
jwks_uri	conditioneel	Tekenreeks die de JSON-websleutelset-URL van dit systeem overbrengt. Vereist als de mogelijkheden van de server sso-openid-connect omvatten; anders optioneel.
authorization_endpoint	Ja	URL naar het OAuth2-autorisatie-eindpunt.
grant_types_supported	Ja	matrix van ondersteunde typen toekenning op het token-eindpunt. De opties zijn: "authorization_code" (wanneer SMART App Launch wordt ondersteund) en "client_credentials" (wanneer SMART Backend Services wordt ondersteund).
token_endpoint	Ja	URL naar het OAuth2-tokeneindpunt.
token_endpoint_auth_methods_supported	optioneel	Reeks client verificatie methoden die worden ondersteund door het tokeneindpunt. De opties zijn "client_secret_post", "client_secret_basic" en "private_key_jwt".
registration_endpoint	optioneel	Indien beschikbaar, URL naar het OAuth2 dynamische registratie-eindpunt voor deze FHIR-server.
scopes_supported	Aanbevolen	Array van scopes die een client kan aanvragen. Zie scopes en startcontext. De server MOET alle hier vermelde scopes ondersteunen; aanvullende scopes KUNNEN worden ondersteund (klanten moeten dit dus niet als een uitputtende lijst beschouwen).
response_types_supported	Aanbevolen	matrix van OAuth2-responstype-waarden die worden ondersteund. Implementers kunnen verwijzen naar response_types gedefinieerd in OAuth 2.0 (RFC 6749) en in OIDC Core.
management_endpoint	Aanbevolen	URL waar een eindgebruiker kan zien welke applicaties momenteel toegang hebben tot data en deze toegangsrechten kan aanpassen.
introspection_endpoint	Aanbevolen	URL naar het introspectie-eindpunt van een server dat kan worden gebruikt om een token te valideren.
revocation_endpoint	Aanbevolen	URL naar het intrekkingseindpunt van een server dat kan worden gebruikt om een token in te trekken.
capabilities	Ja	reeks tekenreeksen die SMART-mogelijkheden vertegenwoordigen (bijv. sso-openid-connect of launch-standalone) die de server ondersteunt.
code_challenge_methods_supported	Ja	reeks van PKCE-code-uitdagingsmethoden ondersteund. De S256-methode MOET in deze lijst worden opgenomen en de gewone methode MOET NIET in deze lijst worden opgenomen.

LET OP: Elk domein krijgt zijn eigen endpoints.

Zie ook: Ldapwiki: Openid-configuration

Rationale

De App Launch specificaties van SMART on FHIR stelt applicaties in staat om op een veilige manier te kunnen starten en gegevens uit te wisselen met andere applicaties binnen het domein van een zorgafnemer.

Implicaties

Voorbeelden

Response SMART Config

HTTP/1.1 200 OK
Content-Type: application/json

{
  "issuer": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2",
  "jwks_uri": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/.well-known/jwks.json",
  "authorization_endpoint": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/auth/authorize",
  "token_endpoint": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/auth/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "private_key_jwt"
  ],
  "grant_types_supported": [
    "authorization_code",
    "client_credentials"
  ],
  "registration_endpoint": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/auth/register",
  "scopes_supported": ["openid", "profile", "launch", "launch/patient", "patient/*.rs", "user/*.rs", "offline_access"],
  "response_types_supported": ["code"],
  "management_endpoint": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/user/manage",
  "introspection_endpoint": "https://fhir.koppeltaal.nl/domeinzorgafnemer/v2/user/introspect",
  "code_challenge_methods_supported": ["S256"],
  "capabilities": [
    "launch-ehr",
    "permission-patient",
    "permission-v2",
    "client-public",
    "client-confidential-asymmetric",
    "context-ehr-patient",
    "sso-openid-connect"
  ]
}

Toepassingsgebied

Onderbouwen

Eisen

Referenties

SIG - Eisen (en aanbevelingen) van het registreren en signaleren van gebeurtenissen

Oude tekst

001. Een applicatie die het abonnement (Subscription resource) aanvraagt (requested), het registreren van een gebeurtenis, wordt de abonnement aanvrager genoemd.

002. Subscription resources (abonnementen) worden (standaard) door applicatie instanties aangevraagd, waarbij de Subscription.status op 'requested' wordt gezet. De volgende validatie moeten worden uitgevoerd:

a. criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

b. Voor Koppeltaal 2.0 wordt alleen het 'rest-hook' kanaal gebruikt (zie: Subscription.channel.type). Dit kanaal wordt gebruikt door een Post bericht (notificatie) naar een URL (Subscription.channel.endpoint) te sturen.

003. Na goedkeuring wordt de Subscription.status op 'active' gezet .

004. De volgende runtime validaties MOETEN worden uitgevoerd, voordat de notificatie wordt verstuurd:

a. de criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

005. De ontvanger van het Post bericht (notificatie) MOET een beveiligd URL (https - Subscription.channel.endpoint) beschikbaar stellen voor ontvangst per type notificatie.

006. In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie: Subscription.channel.payload)

007. Voor het verder specificeren van notificaties voor de ontvanger, adviseren we unieke headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. Alleen op deze manier kan men een notificatie correleren aan één Subscription resource instantie (abonnement)

008. De applicaties mag alleen zijn eigen abonnementen wijzigen en/of verwijderen.

009. Domein beheerders mogen abonnementen wijzigen en/of verwijderen.