Skip to end of metadata
Go to start of metadata

1. Inleiding

1.1. Definitie

Wikipedia: A workflow consists of an orchestrated and repeatable pattern of activity, enabled by the systematic organization of resources into processes that transform materials, provide services, or process information.

Een workflow bestaat dus uit één of meer activiteiten, die na elkaar en/of gelijktijdig kunnen worden uitgevoerd. Activiteiten kunnen zijn opgesplitst in onderdelen. Onderstaande figuur toont het gehanteerde metamodel.

Het concept activiteit (BPMN: Activity) wordt gebruikt als een generieke term voor "werk" dat wordt uitgevoerd door iets of iemand. Een activiteit kan bestaan uit meerdere onderdelen. Een dergelijke activiteit wordt een proces (BPMN: Sub-process) genoemd. Wanneer een activiteit niet verder kan worden opgesplitst in onderdelen, dan wordt gesproken over een taak (BPMN: Task). Een proces bestaat uit één of meerdere andere processen en/of uit één of meerdere taken.

Een taak kent altijd precies één uitvoerder en ook precies één eindverantwoordelijke. Aan een taak kunnen ook een aantal geïnteresseerden worden gekoppeld, zodat zij kunnen worden geïnformeerd over de voortgang en de resultaten van de taak.

Een proces dat bestaat uit één of meerdere taken en/of andere processen kent op het hoogste niveau altijd precies één aanvrager. Wanneer een proces slechts bestaat uit één taak, dan is de aanvrager gekoppeld aan de taak. Wanneer een proces bestaat uit meerdere taken en/of sub-processen, dan is de aanvrager gekoppeld aan het top-level proces. De aanvrager wordt altijd (slechts) geïnformeerd over de voortgang en resultaten van de activiteit waaraan zij is gekoppeld.

In MedMij worden de volgende typen van uitvoerder, geïnteresseerde en aanvrager onderkend:

  1. Een persoon (zowel vertegenwoordiger als vertegenwoordigde)
  2. Een aanbieder
  3. Een device van een aanbieder of van een persoon
  4. Een medewerker van een aanbieder

Een eindverantwoordelijke is altijd een persoon, een aanbieder of een medewerker van een aanbieder.

Aangezien verschillende taken die tot eenzelfde activiteit behoren kunnen worden uitgevoerd door verschillende personen, aanbieders, devices en medewerkers, is het zo dat een workflow zich kan uitstrekken over meerdere organisaties.

In MedMij wordt uit te voeren "werk" slechts gedefinieerd als een afzonderlijke taak, wanneer over de voortgang en/of resultaten ervan moet worden gecommuniceerd via het MedMij koppelvlak. Concreet betekent dit dat voor iedere taak:

  • de uitvoerder een (device van een) persoon is en tenminste één te informeren partij (geïnteresseerde of aanvrager) behoort tot een aanbieder, OF
  • de uitvoerder een (device van een) aanbieder is en tenminste één te informeren partij (geïnteresseerde of aanvrager) behoort tot een persoon.

1.2. Doelstelling

Activiteiten in de zorg, maar ook in andere domeinen, behelzen vaak een bepaalde workflow. In het MedMij afsprakenstelsel zullen afspraken worden opgenomen waarmee de persoon op een gestandaardiseerde, consistente en gebruiksvriendelijke manier, vanuit de PGO, kan participeren in diverse workflows. De wijze waarop dit gebeurd dient zoveel mogelijk aan te sluiten op processen bij aanbieders, en bij hiervoor gehanteerde standaarden.

Aangezien op termijn meerdere organisaties betrokken kunnen zijn bij de uitvoering van eenzelfde workflow, is het van belang dat taken en processen duidelijk en zoveel mogelijk conform gangbare standaarden worden gedefinieerd. Hierbij kan, voor het zorgaanbiederdomein, ondermeer worden gekeken naar vigerende zorgstandaarden en naar technische standaarden, zoals opgesteld door IHE en HL7.

1.3. Scope en fasering

In de eerste fase wordt een basis gelegd die in een later stadium kan worden uitgebreid. In deze eerste fase is de oplossing ingeperkt:

  • Op het MedMij koppelvlak wordt slechts gecommuniceerd over taken.
  • Processen die bestaan uit meerdere taken worden op het koppelvlak nog niet ondersteund.
  • Persoonsdomein en zorgaanbiederdomein.
  • De oplossing dient voldoende ruimte te bieden voor doorontwikkeling, zoals benoemd in de volgende fasen.

In volgende fasen kan de oplossing worden uitgebreid naar:

  • Ondersteuning van communicatie omtrent processen, dus inclusief relaties tussen de taken waaruit een proces bestaat, en de volgordelijkheid ervan.
  • Processen waarbij meer dan één aanbieder betrokken zijn.
  • Andere aanbiedersdomeinen.

Buiten scope:

  • Uitwisseling tussen aanbieders.
  • Uitwisseling tussen personen.
  • Overdragen van workflows tussen DV's.


Use cases die kunnen worden ondersteund in fase 1:

#WorkflowTaakUse case waarin de betreffende taak wordt gecreëerd
1VragenlijstInvullen van vragenlijst door persoonAanbieder vraagt persoon om een vragenlijst in te vullen en op te sturen
2Verwerken van vragenlijst door aanbieder

Persoon vraagt aanbieder om een ingevulde vragenlijst te verwerken

3ZelfmetingenOpleveren van zelfmetingen door persoonAanbieder vraagt persoon om zelfmetingen te delen
4Verwerken van zelfmetingen door aanbieder

Persoon deelt zelfmetingen met een aanbieder

5DossierwijzigingVerwerken van dossierwijzigingsverzoek door aanbieder

Persoon deelt een dossierwijzigingsverzoek met een aanbieder

6

AfspraakVerwerken van afspraak(wijzigings)verzoek door aanbieder

Persoon deelt een afspraak(wijzigings)verzoek met een aanbieder

2. Ontwerp op hoofdlijnen

  1. Een taak, waarbij de Persoon actief is betrokken, kan betrekking hebben op het gebruik van één of meerdere verzamelen- of delen-gegevensdiensten. Persoon kan bijvoorbeeld zelfmetingen simpelweg delen conform de bestaande functie "delen".  Het "delen" kan, door de Persoon of door de Aanbieder, ook worden verbonden aan een taak (waarvan de Persoon of de aanbieder de uitvoerder is).
  2. Uitwisselingen die verlopen conform de bestaande Functie Verzamelen en Functie Delen blijven intact, maar kunnen dus ook plaats gaan vinden in de context van een workflow. Wanneer dit is gewenst, dan is op voorhand niet uit te sluiten dat de informatiestandaard enigszins dient te worden aangepast en hiermee ook een nieuwe gegevensdienst ontstaat. Bij voorkeur is dit natuurlijk niet nodig. E.e.a. zal duidelijk worden in de nadere (technische) uitwerking.
  3. Hetzelfde principe geldt in de toekomst voor modules. Een taak die vanuit de PGO wordt gestart in een bepaalde module kan dan zelfstandig plaatsvinden, maar kan eveneens worden gekoppeld aan een taak binnen een bepaalde workflow.
  4. Voor gegevensdiensten waarin workflow concepten reeds deel uitmaken van de informatiestandaard, geldt dat een mogelijk nieuwe versie van de gegevensdienst/informatiestandaard dient te worden gerealiseerd, zodat gebruik kan worden gemaakt van de generieke workflow functies van het MedMij afsprakenstelsel.
  5. Omdat in de uitvoering van een workflow, meer dan één gegevendienst en/of moduledienst betrokken kan zijn, lijkt het voor de hand te liggen om workflow-gerelateerde interacties buiten de gegevensdiensten en modulediensten onder te brengen.
  6. MedMij stelt persoon in staat om regie te nemen op haar eigen gezondheid. Dit geldt in de basis ook voor het starten van workflows, waar persoon de regie heeft:
    1. Persoon kan op eigen initiatief (periodiek) een workflow starten (een taak creëren)
    2. Persoon kan, bij een aanbieder, middels de Functie Abonneren, een abonnement nemen op het verzamelen van taken
      • Hierdoor kan ook de aanbieder een (vooraf overeengekomen type) workflow starten, en de Persoon, middels de Functie Notificeren, vragen een verzamelverzoek m.b.t. (door aanbieder gestarte) taken te doen
      • Notificaties m.b.t. een reeds gestarte, specifieke, taken in een workflow staan op zichzelf en verlopen niet via de Functies Abonneren en Notificeren
    3. Persoon kan besluiten een taak, waarom wordt verzocht, uit te voeren of te weigeren
  7. Een taak dient informatie te bevatten waarmee desgewenst, na creatie ervan, dynamisch de eindverantwoordelijke, de (initiële) uitvoerder en eventuele geïnteresseerden kunnen worden bepaald.
  8. Workflow is een extensie die, net als abonneren, kan worden geboden door de aanbieder (of zelfs door een Dienstverlener Workflow?), en door de persoon kan worden gebruikt. Activiteiten worden dus (vooralsnog) altijd beheerd en beschikbaar gesteld door DVA's, ook wanneer de uitvoerder of de aanvrager een (device van) een persoon is. In een later stadium, wanneer meerdere aanbieders betrokken kunnen zijn bij een workflow, kan deze keuze worden heroverwogen.
  9. Workflow functionaliteit is optioneel voor zowel DVA’s als DVP’s, maar kan wel zijn vereist voor sommige gegevensdiensten.
  10. De voor workflow benodigde interacties kunnen per type aanbiedersdomein conform een, in het betreffende domein gangbare, informatiestandaard worden uitgewerkt. In het zorgaanbiederdomein wordt gekozen voor HL7-FHIR, omdat hiermee de samenhang met de gegevensdiensten optimaal kan worden geborgd, en omdat FHIR ook al een vrij goede uitwerking bevat van workflow concepten. Met deze keuze wordt het dan wel lastig om workflows te ondersteunen waarin verschillende typen aanbiedersdomeinen betrokken zijn. Moeten we daarom misschien niet toch (net als bij abonneren & notificeren) kiezen voor een generieke standaard (indien beschikbaar) of desnoods weer voor een MedMij-eigen standaard?

Onderstaande figuur toont te relatie tussen taken en bestaande concepten in het MedMij afsprakenstelsel.

In het model is te lezen dat:

  1. De ondersteunding van een taak in MedMij nul of meerdere gegevensdiensten kan vereisen.
  2. De combinatie van een aanbieder en een gegevensdienst altijd door één en slechts één DVA wordt ondersteund.
  3. De ondersteuning van een taak in MedMij, waarvoor bepaalde gegevensdiensten nodig zijn, vereist dat
    1. de DVP van persoon deze gegevensdiensten ondersteund, en
    2. de aanbieder deze gegevensdiensten ook (via een bepaalde DVA) aanbiedt.
  4. Een abonnement kan worden genomen op notificaties betreffende gegevens die uitgewisseld kunnen worden m.b.v. bepaalde gegevensdienst.
  5. Zowel een abonnement als een taak kunnen leiden tot notificaties.

3. Conceptuele uitwerking van de workflow functies

3.1. Aanmaken van een nieuwe taak door Persoon

3.2. Aanmaken van een nieuwe taak door Aanbieder (inclusief abonnement op notificaties)

3.3. Wijzigen van een taak door Persoon

3.4. Wijzigen van een taak door Aanbieder (inclusief notificatie)

4. Wat is nodig voor de eerste fase

Het MedMij afsprakenstelsel zullen in principe slechts afspraken over workflow functies worden opgenomen, wanneer zij plaatsvinden op het koppelvlak tussen DVP en DVA.

Om workflow te ondersteunen in MedMij zijn de volgende aanpassingen en uitbreidingen nodig:

  1. Aanmaken, wijzigen en lezen van een taak door Persoon bij de DVA.
    1. De wijze waarop Persoon een taak kan aanmaken, lezen of wijzigen zal worden beschreven in de MedMij informatiestandaarden. Zo ook de mogelijke statussen die een taak kan hebben, en welke statusovergangen gebruikt kunnen worden. Om consistentie over de verschillende informatiestandaarden heen, en de juiste aansluiting op het afsprakenstelsel te borgen, zullen hiervoor een aantal patronen worden uitgewerkt. Hierdoor wordt tevens de implementatie van workflow bij leveranciers en aanbieders eenvoudiger. Een MedMij informatiestandaard dient deze patronen altijd te volgen.
  2. Notificatie van DVP door DVA, n.a.v. een door Aanbieder aangemaakte of gewijzigde taak bij de DVA.
    1. De wijze waarop DVP dient te worden genotificeerd zal worden beschreven in het MedMij afsprakenstelsel. Wanneer een nieuwe taak wordt aangemaakt door een aanbieder, dan verloopt dit via een, door Persoon af te sluiten, abonnement en een generieke resourcenotificatie. Wanneer een taak is aangemaakt door de Persoon, of wanneer een update plaatsvindt op een bestaande taak, dan kan dit via een taaknotificatie. Het bestaande notificatiemechanisme in MedMij zal hiervoor worden aangepast.
  3. Een nieuwe gegevensdienst, waarmee Persoon taken kan verzamelen bij een Aanbieder. Door Persoon ook toe te staan om abonnementen op notificaties te nemen m.b.t. deze gegevensdienst “verzamelen workflow activiteiten”, wordt het mogelijk voor Aanbieders om taken te creëren, en de Persoon hier via een notificatie van op de hoogte te stellen.

  4. Uitbreiding van de scope van een authorization request, zodat in één actie autorisatie kan worden gevraagd voor alles wat nodig is voor een bepaalde workflow (dus ook: Verzamelen én Delen). In eerste instantie wel bij eenzelfde aanbieder.

  5. DVP moet de inhoud van een (gewijzigde) taak kunnen verkrijgen, zonder dat Persoon eerst opnieuw hoeft in te loggen bij de aanbieder. Zodoende kan DVP bepalen of actie is vereist door Persoon. Dit kan bijvoorbeeld door de taak mee te sturen in een abonnements- of taaknotificatie, of door DVP, middels een abonnements- of taaknotificatie, direct te autoriseren voor het lezen van een taak bij de DVA. Uitzoekpunt is of dit mag en kan o.b.v. reeds verleende toestemming, maar inmiddels verlopen access_token. Belangrijk is ook om rekening te houden met de werkbaarheid wanneer veel taken bestaan bij een aanbieder of persoon, omdat mogelijk iedere notificatie leidt tot een opvraagactie door de persoon. Let op: aan de gewijzigde taak kan ook nieuwe informatie zijn verbonden, waarvoor Persoon mogelijk sowieso expliciet toestemming zal moeten geven, en dus eerst zal moeten inloggen bij de aanbieder.
  6. Inrichting van kwalificatie/acceptatie voor workflow functies en voor het kunnen verwerken van specifieke typen taken. Op het MedMij koppelvlak worden slechts taken uitgewisseld, waarvoor zowel DVP als DVA zijn gekwalificeerd.



  • No labels