Feature Enabling-Technische oplossingsrichting (KPT-807)

Technische oplossingsrichting wordt kort en bondig uitgelegd wat er technisch nodig is om de wens te kunnen realiseren. Dit kan via tekst, plaatjes. Daarnaast wordt toegelicht welke (internationale) standaarden gekozen worden voor toepassing binnen de oplossing.

Uitwerking(en) technische oplossingsrichting

De onderstaande oplossingsrichting is vastgesteld tijdens de TC bijeenkomst van 12/06/2025

Oplossingsrichting

In de onderstaande figuur is schematisch weergegeven hoe features worden toegepast in een Koppeltaal domein.

Voordelen

Per e-health interventie (ActivityDefinition) wordt aangegeven welke features nodig zijn.
Module leveranciers hebben de vrijheid om bij elke e-health interventie aan te geven welke features van toepassing zijn voor die specifieke interventie.
Geen grote verandering nodig aan het kwalificatie- en acceptatieproces.
Per Koppeltaal domein kan worden gekozen voor het gebruik van de voor haar relevante features.
De Koppeltaal standaard houdt controle over de features die ontwikkeld worden in de standaard en bruikbaar zijn in Koppeltaal domeinen

Nadelen

Geen controle vanuit de FHIR store dat module leveranciers enkel e-health interventies aanmaken met features waar ze voor gekwalificeerd zijn.
Geen controle dat applicatie die een module launcht de benodigde features ondersteund.
Geen controle vanuit de FHIR store dat een applicatie geaccepteerd is op het gebruik van een feature bij het aanmaken en launchen van een e-health interventie die bepaalde features vereist.

Er is een risico dat applicaties gebruik gaan maken van features waar ze niet voor gekwalificeerd en geaccepteerd zijn. Echter, het is van belang van de applicaties zelf om hier geen misbruik van te maken, omdat ze dan een slechte dienstverlening aan haar klanten zou geven. Daarom is dit een acceptabel risico.

ActivityDefinition

Om feature enabling mogelijk te maken kan in de ActivityDefinition de useContext parameter worden toegevoegd, zie definitie hieronder:

ActivityDefinition.useContext

The content was developed with a focus and intent of supporting the contexts that are listed. These contexts may be general categories (gender, age, ...) or may be references to specific programs (insurance plans, studies, ...) and may be used to assist with indexing and searching for appropriate activity definition instances.

De useContext-parameter sluit goed aan bij de vereisten voor feature enabling in Koppeltaal. Deze parameter maakt gebruik van een UsageContext, waarin met een CodeableConcept kan worden aangegeven in welke context een ActivityDefinition toepasbaar is.

Om feature enabling in Koppeltaal te ondersteunen, kan voor elke feature een specifieke usageCode worden gedefinieerd. Vervolgens kan de ActivityDefinition worden voorzien van een UsageContext, zodat applicaties kunnen bepalen of ze de benodigde features ondersteunen. Zie hieronder een voorbeeld van een UsageContext:

JSON

"usageContext": [
    {
      "code": {
        "system": "http://terminology.hl7.org/CodeSystem/usage-context-type",
        "code": "feature"
      },
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://example.org/CodeSystem/koppeltaal-features",
            "code": "Naaste:Ouders",
            "display": "een van de ouders van de cliënt"
          }
        ]
      }
    }
  ]

MVP oplossing

Er is aangegeven dat een minimal viable product (MVP) oplossing voor feature enabling gewenst is. De volledige oplossing (hierboven) voor feature enabling is complex en heeft een impact op veel verschillende aspecten. Daarom wordt hieronder de aspecten geschetst die van belang zijn voor een MVP oplossing.

Suggestie MVP-oplossing

UseContext als optioneel toevoegen aan het ActivityDefinition profiel.
Toevoegen van een Search query parameter voor UseContext.
UseContext code definiëren voor Related Person.
Acceptatie op niveau van individuele features moet per feature worden bekeken.

Wat hebben we dan wel:

Een manier waarop module leverancier kunnen aangeven welke features nodig zijn per ActivityDefinition.
Related Person als optionele feature.
Meerdere features per activityDefinition zijn mogelijk.
Een manier waarop ECDs kunnen zoeken op ActivityDefinition met features bij het toewijzen van Tasks.
Features zouden moeten meegenomen worden in het huidige acceptatie proces.

Wat hebben we dan niet:

Geen technische controles of applicaties juist kunnen omgaan met features in modules (bij registreren, toewijzen of launchen van modules). Afspraken zijn nodig om:
- Applicaties mogen enkel modules registreren indien ze kunnen garanderen dan de feature ondersteund is.
- Applicaties hebben geen controle of verantwoordelijkheid om features te controleren bij het toewijzen van modules
- Applicaties mogen enkel modules launchen als de applicatie de feature ondersteund.
- Er moet implicieten afspraken worden gemaakt tussen applicaties die modules toewijzen en applicaties die modules launchen over de ondersteuning van features. Er bestaat een risico dat een module wordt toegewezen die niet gelauncht kan worden. Dit moet worden gemitigeerd worden.
Geen technische garantie of features werken volgens de specificatie.
Alles features in de UseContext zijn verplicht, optionele features zijn niet mogelijk.
Elke feature moet met een code worden geduid, er is beperkte granulairiteit van features.