Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 285 Next »

Inleiding

Definitie

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. Onderstaande figuur toont het gehanteerde metamodel.

Een workflow beschrijft werk dat wordt uitgevoerd door iets of iemand, en bestaat uit één of meerdere taken (BPMN: Task). Een workflow kent altijd één aanvrager en één procesbeheerder. In een latere fase zal het mogelijk worden om in de rol van geïnteresseerde op de hoogte te worden gehouden van het bestaan en van de voortgang van workflows. Een taak kent altijd één uitvoerder.

Definitie van de rollen:

Business rolDefinitie
AanvragerDegene (mens of organisatie) die een workflow aanvraagt/initieert.
UitvoerderDegene (mens of organisatie) die een taak binnen een workflow daadwerkelijk uitvoert (RACI: "responsible").
Procesbeheerder

Degene (mens of organisatie) die de voortgang van een workflow bewaakt en bestuurt. 

  • Bewaken houdt in dat een beheerder het signaleert wanneer een workflow instantie stagneert, en de aanvrager hierover notificeert. De beheerder draagt geen verantwoordelijkheid voor de succesvolle uitvoering van workflows.
  • Besturen houd in dat een beheerder na afronding van een taak een volgende taak kan starten, of de workflow kan beëindigen. Besturing is noodzakelijk wanneer een activiteit bestaat uit verschillende taken die simultaan kunnen worden uitgevoerd, en de afronding van de ene taak dus niet automatisch leidt tot het starten van de volgende taak. 
GeïnteresseerdeDegene (mens of organisatie) die is geïnteresseerd in het verloop van een workflow of taak (RACI: "informed").

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 (systeem of apparaat) van een aanbieder of van een persoon
  4. Een medewerker van een aanbieder

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

Granulariteit van taken

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. 

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 gebeurt 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.

Ontwerp op hoofdlijnen

  1. In het MedMij afsprakenstelsel zullen in principe slechts afspraken over workflow functies worden opgenomen, wanneer informatie moet worden uitgewisseld

    1. tussen Persoon en een bij de workflow betrokken Aanbieder
    2. tussen Aanbieders die bij eenzelfde workflow zijn betrokken
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. Omdat in de uitvoering van een workflow, meer dan één gegevendienst en/of moduledienst betrokken kan zijn, worden workflow-gerelateerde interacties, zoals het aanmaken en wijzigen van een taak, buiten de gegevensdiensten en modulediensten ondergebracht. Hetzelfde geldt voor het generieke informatiemodel van een taak. Deze aspecten worden dus generiek gespecificeerd en hoeven slechts één maal te worden geïmplementeerd. Binnen een gegevensdienst of moduledienst dient wel worden gespecificeerd, op welke wijze, de interacties die deel uitmaken van een dienst kunnen worden gebruikt binnen taken in een workflow.
  7. Notificaties (aan aanvragers, uitvoerders en/of geïnteresseerden) verlopen via de MedMij Functies Abonneren en Notificeren, en maken dus geen deel uit van de workflow functionaliteit zelf.
    1. Persoon moet kunnen opvragen welke abonnementen zij heeft genomen
  8. MedMij stelt persoon in staat om regie te nemen op haar eigen gezondheid. Dit geldt in de basis ook voor het starten van workflows:
    1. Persoon kan op eigen initiatief (periodiek) een workflow starten
    2. Persoon kan, bij een Procesbeheerder, middels de Functie Abonneren, een abonnement nemen op een type workflow
      • 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
      • Persoon mag, per type workflow, bij eenzelfde Procesbeheerder, slechts één abonnement afsluiten
    3. Persoon kan besluiten een taak, waarom wordt verzocht, uit te voeren of te weigeren
  9. Ook aanbieders kunnen regie nemen op workflows:
    1. Aanbieder kan op eigen initiatief (periodiek) een workflow starten
    2. Aanbieder kan besluiten een taak, waarom wordt verzocht, uit te voeren of te weigeren
  10. Een uitvoerder geeft middels de registratie van een abonnement in een nieuwe, centrale MedMij lijst aan dat zij open staat voor taken i.h.k.v. één of meerdere typen workflow. Zonder abonnement van een beoogd uitvoerder kan geen taak worden aangemaakt voor de betreffende uitvoerder. Hoe e.e.a. gaat werken voor geïnteresseerden wordt in een later stadium uitgewerkt.
  11. Een taak dient informatie te bevatten waarmee desgewenst, na creatie ervan, dynamisch de (initiële) uitvoerder en eventuele geïnteresseerden kunnen worden bepaald.
  12. Binnen een taak kan door betrokken partijen met elkaar worden gecommuniceerd (tekst). Deze communicatie wordt gekoppeld aan de desbetreffende taak.
  13. Workflow is een extensie die, net als abonneren, kan worden geboden door de aanbieder, en door de persoon kan worden gebruikt. Workflow functionaliteit is optioneel voor zowel DVA’s als DVP’s, maar kan wel zijn vereist voor sommige gegevensdiensten, omdat ze slechts goed kunnen functioneren in de context van een beheerder workflow (denk aan vragenlijsten).

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

In het model is te lezen dat:

  1. De ondersteuning 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 ondersteunt, en
    2. de aanbieder deze gegevensdiensten ook (via een bepaalde DVA) aanbiedt.
  4. Een abonnement leidt tot notificaties betreffende gegevens die uitgewisseld kunnen worden m.b.v. bepaalde gegevensdienst of tot notificaties die betrekking hebben op een bepaalde type workflow.

Open issues

Tijdens de uitwerking zijn een aantal vraagstukken opgekomen, die nog nader moeten worden uitgezocht en/of waarover nog een besluit moet worden genomen.

Issue m.b.t. fase 1:

  1. Technische standaard voor workflow interacties - HL7-FHIR, OF MedMij equivalent (JSON REST based) van de betreffende FHIR-profielen (door DVA intern te transformeren naar FHIR).
    1. In het zorgaanbiederdomein is de transitie ingezet naar HL7-FHIR, en bieden steeds meer systemen een FHIR-koppelvlak.
    2. Het overgrote deel van de aanbieders die een rol spelen binnen MedMij is zorgaanbieder.
    3. Wanneer gewerkt wordt met een MedMij equivalent, dan wordt dit per definitie, in geen enkel domein out-of-the-box ondersteund door leveranciers, en zijn dus implementaties of vertalingen nodig.
    4. Om bovenstaande redenen wordt vooralsnog gekozen om te werken met HL7-FHIR.
    5. Na de eerste PoC's en pilots kan dit worden heroverwogen.

Issues m.b.t. latere fasen:

  1. Moet het ook mogelijk zijn dat een aanbieder een eigen invulling kan geven aan en workflow? Mogelijk ook afhankelijk van de exacte casus. Waarschijnlijk moet dit kunnen. MedMij streeft in beginsel namelijk niet naar standaardisatie van zorgprocessen, wel naar meer regie voor Persoon.
  2. Onderlinge interactie tussen aanbieders
    1. hoe identificeren, authenticeren en autoriseren?
    2. gevolgen voor afsprakenstelsel in het algemeen.
    3. welke type gegevens uitwisselen via MedMij (bijv. procesgegevens en referenties naar medische inhoud), welke via andere afsprakenstelsels (bijv. medische inhoud)?
  3. Zijn er workflows, waarbij het meer voor de hand ligt dat Persoon (of DVP namens Persoon) de rol van beheerder vervult?
  4. Op welke wijze geven geïnteresseerden aan dat ze notificaties wensen te ontvangen m.b.t. een bepaald type workflow (en eventueel voor bepaalde BSN's)? Welke autorisatie moet hiervoor plaatsvinden? Hoe wordt Persoon hierbij betrokken?

Scope en fasering

Omdat workflow een omvangrijk en complex onderwerp is, wordt de ondersteuning ervan verspreid over een aantal fasen. Toekenning van onderwerpen aan fase 2 en erna is slechts een indicatie.

#OnderwerpFase 1Fase 2Fase 3
1Omvang van workflow

Ondersteuning van taken. Processen die bestaan uit meerdere taken worden nog niet ondersteund.

Ook ondersteuning van processen, dus inclusief relaties tussen de taken waaruit een proces bestaat, en de orkestratie ervan conform een formele, machine-leesbare workflow-definitie.


2Betrokken domeinen

Betrokkenen in een workflow behoren tot het persoonsdomein of tot het zorgaanbiederdomein.


Ook andere domeinen, bijv. WLZ-domein.
3Ondersteunde rollen

Ondersteunde rollen zijn die van aanvrager, procesbeheerder en uitvoerder (nog geen ondersteuning van geïnteresseerde).


Ook ondersteuning van geïnteresseerde. 
4Invulling rol van beheerderDe rol van procesbeheerder wordt altijd vervuld door een aanbieder.N.t.b. mogelijk kan ook persoon/DVP de rol van procesbeheerder vervullen.
5Aantal betrokkenen

De betrokkenen per workflow zijn beperkt tot persoon en één aanbieder. Ondersteunde situaties zijn derhalve:

  • Persoon is aanvrager; aanbieder is procesbeheerder en uitvoerder.
  • Aanbieder is aanvrager en procesbeheerder; persoon is uitvoerder.

Ook processen waarbij meer dan één aanbieder betrokken zijn. Dit betekent dat ook aanbieder-aanbieder communicatie moet worden ondersteund binnen MedMij.


Buiten scope:

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


Voorbeelden van workflows die kunnen worden ondersteund in fase 1:

#ActiviteitTaakUse case waarin de betreffende taak wordt gecreëerd
1Vragenlijst *Invullen 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

3Zelfmetingen *Opleveren 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

7VerwijzingIndienen van afspraakverzoek door persoonAanbieder vraagt persoon om een afspraak te maken met een andere aanbieder
8HerhaalmedicatieIndienen van verzoek voor herhaalmedicatie door persoonPersoon vraagt aanbieder om een hernieuwd recept en bijbehorend verstrekkingsverzoek naar de apotheek
9e-Consult ??Beantwoorden van vraag door aanbiederPersoon stelt aanbieder een vraag m.b.t. haar gezondheid
10WLZ IndicatieVerwerken indicatieaanvraag door CIZPersoon vraag CIZ om een indicatiebesluit t.b.v. langdurige zorg

*) Bij deze workflow wordt de onderlinge relatie tussen de taken waaruit ze bestaan, en de orkestratie ervan conform een formele, machine-leesbare, workflow-definitie nog niet ondersteund.

Impact op afsprakenstelsel en op gegevensdiensten

Impact op afsprakenstelsel

Onderstaande tabel toont welke RFC's, t.b.v. fase 1, moeten worden uitgewerkt in het afsprakenstelsel.

#RFCToelichting
0Workflow catalogusBenodigde functionaliteit voor een workflow catalogus in de RnA, en het voor deze fase benodigde formaat van een workflow definitie.
1

Verruimen scope van authorization request.

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, mogelijk ook samen met gebruik van een bepaalde gegevensdienst, inclusief abonneren op verzamelen en/of workflow). Wel bij eenzelfde aanbieder.

NB. deze functionaliteit is ook bruikbaar voor verzamelen, delen en abonneren buiten een workflow context.

2

Persoon neemt abonnement op een type workflow.

Hierbij wordt gebruik gemaakt van de verruimde autorisatie mogelijkheden uit RFC #1.

3Persoon zoekt naar (of vraagt haar Abonnementen op) bij een Subscription Server (Procesbeheerder).

Deze functie is pas echt noodzakelijk wanneer ook aanbieders abonnementen kunnen nemen op workflows waarbij Persoon betrokken is, zodat Persoon hier kennis van kan nemen.

NB. deze functionaliteit is ook bruikbaar voor abonneren buiten een workflow context.

4Verrijken bestaande resource notification met task.id en met assertion.

Een assertion is vereist om de betreffende resource zonder tussenkomst van de genotificeerde persoon te kunnen ophalen. Deze uitbreiding is vereist om workflows gebruiksvriendelijk te maken, en kan ook worden gebruikt om DVP Server automatisch gegevens te laten verzamelen of delen binnen een bestaande gegevensdienst.

Hierbij ook kijken naar uitwerking van een generiek mechanisme voor "notified pull" interacties die momenteel wordt uitgewerkt voor zorgaanbieder-zorgaanbieder uitwisseling, i.h.k.v. VIPP 5. Een notificatie zou dan altijd gepaard met van een Task voor de ontvanger van de notificatie. Dit kan een Task zijn i.h.k.v. workflow, maar ook een Task om iets (opnieuw) te verzamelen of te delen bij of met een aanbieder.

NB. deze functionaliteit is ook bruikbaar voor abonneren buiten een workflow context.

5Automatisch verzamelen of delen van gegevens o.b.v. resource notification met een assertion.

Specifiek voor workflow dient het mogelijk te zijn om automatisch taken te lezen en te wijzigen.

Een assertion wordt, bij bestaan van een geldig en actief Abonnement, gegenereerd door DVA en dient als een Authorization Grant op basis waarvan een access_token kan worden afgegeven (analoog aan de authorization code in de reguliere MedMij flow).

Zie ook RFC 7523.

NB. deze functionaliteit is ook bruikbaar voor verzamelen, delen en abonneren buiten een workflow context.

6Persoon maakt, leest of wijzigt een taak bij Workflow Server (Procesbeheerder). Inclusief zoeken naar taken bij een Workflow Server.
7

Aanbieder maakt, leest of wijzigt een taak bij Workflow Server (Procesbeheerder). Inclusief zoeken naar taken bij een Workflow Server.

Nodig zodra wordt gewerkt met  meerdere aanbieders in eenzelfde workflow, bijvoorbeeld omdat een workflow bestaat uit meerdere taken.

Impact op gegevensdiensten

TODO, Nictiz?

Referenties

BPMN 2.0

Efficient Distributed Control of Enterprise-Wide and Cross-Enterprise Workflows

IHE XDW

Workflow binnen FHIR




  • No labels