Koppeltaal 2.0 Implementation Guide (Full Documentation)
0.15.0 - ci-build
NL
Koppeltaal 2.0 Implementation Guide (Full Documentation)
0.15.0 - ci-build
NL
Koppeltaal 2.0 Implementation Guide (Full Documentation) - Local Development build (v0.15.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
| Page standards status: Draft |
Document: Koppeltaal 2.0 - CareTeam Autorisaties Referentie: CareTeam en Autorisaties
"Voor autorisatie moeten alle betrokkenen (incl. relatedPersons) met hun correcte rol in het Careteam staan." (Basisprincipes)
Betekent dit dat de rol v/d relatedPerson in de relatedPerson resource niet gebruikt gaat worden voor autorisatie? In dat geval kan daar de verplichting van het relationship element afgehaald worden.
Je zegt het correct, het gaat (vooralsnog) niet gebruikt worden voor autorisatie. Niet alle velden worden gebruikt voor autorisatie, of daarmee het veld ook moet verdwijnen gaat een beetje ver 🙃.
"Task.owner moet lid zijn van het relevante CareTeam" (Basisprincipes)
Vragen:
Deze zinsnede lijdt een beetje onder de beslissing meerdere CareTeams toe te staan. Dit wordt aangepast naar meervoudigheid.
De cliënt moet als CareTeam.subject geregistreerd staan; de rol met zichzelf is daarmee duidelijk.
Het concept van een 'Zorgteam' in jullie systeem kan afwijken van de definitie in Koppeltaal. In Koppeltaal wordt gekozen voor Type 2: Patiënt-specifieke CareTeams. Indien jullie Type 1 gebruiken is dat geen probleem voor de communicatie met Koppeltaal.
"Task.requester moet lid zijn van het relevante CareTeam" (Basisprincipes)
Dit is in tegenspraak met de scope: "administratieve medewerkers die taken klaarzetten hoeven niet in het CareTeam te staan als verder geen deelnemer zijn in het zorgproces." (Scope van het CareTeam)
Naar mijn inzicht niet in tegenspraak. In dat geval zijn administratieve medewerkers geen Task.requester. Let wel dat in jullie applicatie meer rollen en rechten kunnen bestaan dan in Koppeltaal zich manifesteren. Koppeltaal gaat over de informatie die we met elkaar uitwisselen, niet de interne staat van jullie systeem.
"Een CareTeam kan niet direct Task.owner zijn" (Besluiten en Richtlijnen)
Hoewel ik het hiermee eens ben, is dit in tegenspraak met de beschrijving van Task level CareTeams.
Leverancier A had dezelfde opmerking. Dit is inmiddels aangepast in het document, zie het changelog.
Validatieregel: "Als Task.requester is ingevuld MOET deze persoon lid zijn van een CareTeam van Task.for (patient)" (Validatieregels)
Dit is in tegenspraak met de scope over administratieve medewerkers. Deze regel komt op verschillende plaatsen terug en is in strijd met de uitgangspunten: Een administratief medewerker die een taak klaarzet voor de cliënt (als Task.requester) heeft niet automatisch toegang tot de taak. Deze medewerker heeft alleen toegang als hij lid is van het (een) Careteam met een rol die toegang geeft. Daarom zal de aanvrager niet automatisch lid worden van het Careteam maar alleen als toegang nodig is.
Zie 3. Task.requester en CareTeam lidmaatschap.
"Zoon heeft rol 'eerste relatie' in het CareTeam" (SMART on FHIR Launch en Autorisatie)
Rol "eerste relatie" is geen reden voor autorisatie en geen rol in RelatedPerson Authorization.
De RelatedPerson heeft nu in het profiel geen rol. Dit zou ter hoogte van de discussie rond de rollenmatrix kunnen veranderen. In principe is de rollenmatrix out of scope voor dit document.
Eens met de besluiten en richtlijnen — Akkoord.
Impact op KT2_CareTeam resource — Er zijn op basis van de vragen een aantal dingen verduidelijkt en aangepast. Zie het changelog boven in de pagina.
In de voorbeeld JSON representatie van een HTI token onder "Launch door portaalapplicatie" wordt fhirUser genoemd. Ik kan noch in de HTI documentatie noch in de Koppeltaal documentatie die de launch beschrijft, deze key terugvinden. Waar komt deze key vandaan en wat betekent deze key?
Dit komt van KoppelMij, het voorbeeld was verkeerd en is aangepast. Zie changelog.
Onder de besluiten en richtlijnen staat expliciet "Een CareTeam kan niet direct Task.owner zijn". Volgens mij hebben we aangegeven n.a.v. het leveranciers overleg, dat een Task.owner wat ons betreft wél naar een CareTeam mag wijzen, als zijnde het team van mensen dat verantwoordelijk is deze taak uit te voeren. Die use-case wordt op dit moment niet gebruikt, maar zouden we niet bij voorbaat willen afsluiten voor de toekomst.
Het issue met Task.owner = CareTeam is dat dan onduidelijk is wie de uitvoerder is en dat heeft ter hoogte van een ander project (OZO) tot wat migraine geleid. De beperking is verwijderd en er is aangegeven dat het een specifieke use case betreft. Zie changelog.
Leverancier A geeft aan dat het over het geheel genomen een goede en werkbare weergave is van de plannen die zijn geformuleerd.