RFC 24055 Aanpassing GraphQL Bemiddelingsregister t.b.v. autorisatie

[rvanrest]

eDocs volgnummer

2024024634

Korte probleem omschrijving

Voor het toepassen van de autorisatieregels is het noodzakelijk dat de GraphQL specificaties aanvullende filter-parameters bevatten.

Deze zitten niet in de huidige specificatie.

Korte omschrijving voorgestelde oplossing

Toevoegen generieke filter en input - parameters.

Om de wijzigingen op het koppelvlak te beperken worden er generieke parameters toegevoegd. De specifieke toegestane queries bevatten de beperkingen van die parameters.

RFC gevolgen voor het onderdeel/de onderdelen

Koppelvlak specificatie

Welk ander onderdeel?

No response

Betrokken partij RFC

Zorgkantoor

Andere betrokken partij

VECOZO

Indiener RFC

anders, (geef aan bij contactpersoon)

Andere organisatie / contactpersoon

VECOZO

Analyse

Huidige situatie

De huidige versie van de GraphQL koppelvlak specificatie bevat geen mogelijkheden om informatie te filteren. Bijvoorbeeld door eisen te stellen aan de input, mee te geven variabelen.

huidige versie: v1.0.0 op https://github.com/iStandaarden/iWlz-bemiddeling

Bezwaren huidige situatie

Het meegeven van verplichte zoek variabelen als bijvoorbeeld BemiddelingspecificatieID i.c.m. het ID van de raadpleger (uzovicode of agbcode) is niet mogelijk.

Daarnaast vereist de huidige opzet dat er bij nieuwe wensen of autorisatie voorwaarden een nieuwe bron graphql-schema moet worden geimplmenteerd.

Wijzigingsvoorstel

Voorstel aanpassing

1. Voor elk Object-type komt er een:

• filtertype equivalent. Reden:
• sorttype equivalent. Reden:

Hier mee wordt het mogelijk om filtering toe te passen waarop autorisatie kan worden bepaald.

Query {
    bemiddelingspecificatie(where: BemiddelingspecificatieFilterInput): [Bemiddelingspecificatie!]!
}

type Bemiddelingspecificatie {
  bemiddelingspecificatieID: UUID!
  ...
  bemiddeling: Bemiddeling!
  overdrachtspecificatie: Overdrachtspecificatie
}

input BemiddelingspecificatieFilterInput {
  and: [BemiddelingspecificatieFilterInput!]
  or: [BemiddelingspecificatieFilterInput!]
  bemiddelingspecificatieID: UuidOperationFilterInput
  ...
  instelling: StringOperationFilterInput
  ...
  bemiddeling: BemiddelingFilterInput
  overdrachtspecificatie: OverdrachtspecificatieFilterInput
}

input StringOperationFilterInput {
  and: [StringOperationFilterInput!]
  or: [StringOperationFilterInput!]
  eq: String
  neq: String
  contains: String
  ncontains: String
  in: [String]
  nin: [String]
  startsWith: String
  nstartsWith: String
  endsWith: String
  nendsWith: String
}

Voorbeeld: Schema query voor het ophalen van bemiddelingsspecificatie gegevens door een zorgaanbieder.

# QBR-0001-ZA.graphql
# Query voor Zorgaanbieder op Bemiddelingsregister
# Verplichte input:
#   - bemiddelingspecificatieID
#   - agbcode instelling

query Bemiddelingspecificatie(
  $BemiddelingspecificatieID: UUID!
  $Instelling: String!
) {
  bemiddelingspecificatie(
    where: {
      bemiddelingspecificatieID: { eq: $BemiddelingspecificatieID }
      instelling: { eq: $Instelling }
    }
  ) {
    bemiddelingspecificatieID
    leveringsvorm
    zzpCode
    toewijzingIngangsdatum
    toewijzingEinddatum
    instelling
    uitvoerendZorgkantoor
    vaststellingMoment
    percentage
    opname
    redenIntrekking
    etmalen
    instellingBestemming
    soortToewijzing
    bemiddeling {
      bemiddelingID
      wlzIndicatieID
      verantwoordelijkZorgkantoor
      verantwoordelijkheidIngangsdatum
      verantwoordelijkheidEinddatum
      # Overige Bemiddelingspecificaties van de bemiddeling mag je niet ophalen zonder datumfilter
      client {
        bsn
        clientID
        taal
        communicatievorm
        huisarts
        leefeenheid
        # Sub entiteiten van de client mag je niet ophalen zonder datumfilter
      }
    }
  }
}

Voorbeeld: onderdeel query ophalen aanvullende bemiddelingsspecificaties door een zorgaanbieder:

query Bemiddelingspecificatie(
  $BemiddelingspecificatieID: UUID!
  $Instelling: String!
  $ToewijzingIngangsdatum: Date!
  $ToewijzingEinddatum: Date!
  $ToewijzingEinddatum2Jaar: Date!
  $ToewijzingEinddatum31Mei: Date!
) {
  bemiddelingspecificatie(
    where: {
      bemiddelingspecificatieID: { eq: $BemiddelingspecificatieID }
      instelling: { eq: $Instelling }
      toewijzingIngangsdatum: { eq: $ToewijzingIngangsdatum }
      toewijzingEinddatum: { eq: $ToewijzingEinddatum }
    }
  ) {
    bemiddelingspecificatieID
    ...
    bemiddeling {
        bemiddelingspecificatie(
            where: {
            and: [
                {
                or: [
                    { toewijzingEinddatum: { eq: null } }
                    { toewijzingEinddatum: { gte: $ToewijzingIngangsdatum } }
                ]
                }
                { toewijzingIngangsdatum: { ngt: $ToewijzingEinddatum31Mei } }
            ]
            }
        ) {
            bemiddelingspecificatieID
            ...
        }
    }
  }

2. Contactgegevens worden in de koppelvlak specificatie specifiek gemaakt voor Client en Contactpersoon naar respectievelijk ClientContactgegevens en ContactpersoonContactgegevens.

Reden: directe relatie met juiste object

Voordelen

• noodzaak voor rol-autorisatie
• Toekomstigbestendigheid

Nadelen

• aanpassing specificaties

3. Toevoegen verantwoordelijkZorgkantoor aan Client
Door het toevoegen van verantwoordelijk zorgkantoor aan Client is het eenvoudiger clienten te selecteren die horen bij een zorgkantoor

Voordelen

• eenvoudig filteren

Nadelen

• aanpassing specificaties
• Dezelfde client (Bsn) meerdere malen opnemen

Uitwerking wijzigingsvoorstel per onderdeel

ERD

n.v.t.

Regels

n.v.t.

Proces

n.v.t.

Gegevens

n.v.t.

Koppelvlak

Uitwerking voorstel zie in de branch Autorisatie in de iWlz-bemiddeling repository / autorisatie-branch

Overweging wijzigingsvoorstel(len)

Voorstel	Voordeel / Nadeel	Overweging
1. Toevoegen generieke filter- en sorttypen	Voordeel: - generieke GraphQL principe - geen extra filterimplementatie meer nodig bij nieuwe query-wensen	Doorvoeren want er is nu nog ruiimte voor
	Nadeel: aanpassing nodig
2. Splitsen contactgegevens	Voordeel: direct juiste type	Doorvoeren
	Nadeel: aanpassing nodig
3. Toeveogen verantwoordelijkZK aan client	Voordeel: makkelijk filteren
	Nadeel: dubbele bsn	Niet doorvoeren: via Bemiddeling is te achterhalen wie verantwoordelijk is en bij wie de client op dat moment hoort
5. Niets doen	Voordeel: geen wijziging nodig
	Nadeel: probleem blijft aanwezig
...

Conclusie

Voorstellen 1 en 2 doorvoeren. Voorstel 3: niet doorvoeren. Zie de iWlz-bemiddeling repository / autorisatie-branch

Gekozen oplossing

No response

Publicatiemoment

No response

Implementatiemoment

No response

controleer project en labels van het issue

• gecontroleerd

[rvanrest]

2024-06-20: Besproken in Technisch afstemmingsoverleg.

• specificatie aanvullen met 'generieke' filter, sorteer functionaliteit is akkoord
  • direct aanvullen met pagination and relay functionaliteit
• splitsing contactgegevens is akkoord
• toevoegen verantwoordelijkzorgkantoor aan Client is niet akkoord

Eerste versie zal worden gepubliceerd in GitHub in aparte Branch.