Versions Compared

Old Version 3

changes.mady.by.user Casper van der Harst

Saved on

compared with

New Version Current

changes.mady.by.user Casper van der Harst

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Vanuit verschillende richtingen is de wens uitgesproken dat Zorgverleners en Zorggebruikers vanuit workflows elkaar opdrachten/taken moeten kunnen geven. Door het geven van een eerste opdracht wordt een workflow gestart en binnen de grenzen van de workflow moeten de taken uitgevoerd worden. De invoering van workflows zorgt er voor dat de Zorggebruiker en dus de PGO meer betrokken worden bij het zorgproces en dat opdrachten asynchroon uitgevoerd kunnen worden, zonder direct contact tussen Zorgverlener en Zorgaanbieder.

Numberedheadings
number-formatdecimal
skip-headings
start-numbering-with
h1
h2
h3
h4
h5
h6
enabledtrue
start-numbering-atH1
add-anchorsfalse

Doel van het project

Binnen het minimum viable product (MVP) is het van belang de implementatie zo simpel mogelijk te houden, maar wel waarde te bieden aan de gebruikers. Voor het onderwerp workflow betekent dit dat de Zorgverlener en Zorggebruiker elkaar taken moeten kunnen geven en terugkoppeling krijgen als de taken zijn uitgevoerd. Eventuele vervolgstappen worden niet in het MVP meegenomen, het gaat in deze fase om enkelvoudige taken.

Wel moet rekening worden gehouden met het feit dat Zorgaanbieders moeten weten waar zij een Zorggebruiker kunnen vinden. In het stelsel moet bekend zijn welke PGO door de Zorggebruiker wordt gebruikt. Hiervoor wordt gedacht aan een implementatie van de functie Abonneren, maar eventueel kan een wijziging in de werking van toestemmingen ook volstaan.

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 zorgaanbiederdomeinzorgdomein, ondermeer worden gekeken naar vigerende zorgstandaarden en naar technische standaarden, zoals aanbevolen en/of opgesteld door IHE en HL7.

Betrokken architecten

  • (Lead architect)

  • (Solution architect)

Stakeholderanalyse

(Lead architect) (Solution architect)C

Idee

VooronderzoekReady

Alpha uitwerking

Alpha POC

Beta uitwerking

Beta Pilot

Release candidate

Publicatie

Kernteam ontwikkeling

A

I

I

I

I

I

A

A

Product manager

R

A

A

I

A

I

C

I

Lead architect

I

R

C

C

C

C

C

I

Release manager

I

R

C

Afsprakenstelsel

I

C

R

C

R

C

C

R

AcceptatieReferentie implementatie

C

C

C

C

I

Proves

I

A

I

A

I

Monitoring

C

C

I

Testomgeving

C

C

C

C

I

Acceptatie

C

C

C

I

Deelnemers

(I)

C

R

C

R

C

I

Zorgaanbieders

C

C

I

C

I

I

Juristen

C

I

C

I

Kernteam ontwikkeling

Het kernteam is eindverantwoordelijk voor het prioriteren van een idee, het plannen van een release candidate en de daadwerkelijke publicatie van een onderwerp. Tussen die fases wordt het kernteam geïnformeerd over de voortgang , zodat er indien nodig gestuurd kan worden.

Scope

In scope

  • Abonneren op taken door de Zorggebruiker (PGO) bij de Zorgaanbieder (DVA)

  • Workflow starten door taak aan te maken

  • Taken van de Zorgverlener voor de Zorggebruiker

    • Notificeren van klaarstaande taken door DVA aan PGO en daarmee de Zorggebruiker

    • Verzamelen van taken door de PGO

    • Uitvoeren van taken

    • Delen van resultaat met de DVA en daarmee met de Zorgaanbieder en Zorgverlener

  • Taken van de Zorggebruiker voor de Zorgaanbieder

    • Delen van de taak met de DVA door de PGO

    • Notificeren van de klaarstaande resultaten dor de DVA aan de PGO en daarmee de Zorggebruiker

    • Verzamelen van de resultaten door de PGO

Dit alles wordt uitgevoerd met de al beschikbare functies. Taken kunnen bestaat uit het ophalen van gegevens, het delen van gegevens en het uitvoeren van een module.

Buiten scope

  • Herhalende en gelaagde taken

  • Generieke functies

    • Vertrouwde authenticatie

    • Toestemmingen

    • Lokalisatie

  • Machtigingen / vertegenwoordiging

  • Workflows met meerdere (achtereenvolgende) taken.

  • Bij Zorgaanbieders aanwezige workflow-oplossingen.

Betrokken architecten

I

Security

C

C

I

R&A

C

C

I

I

CCDA

C

I

I

Leveranciers management

I

I

I

I

Loket

I

I

Usecases op het hoogste niveau

  • Als Zorgverlener wil ik in het kader van een behandeling een taak naar een Zorggebruiker kunnen sturen, met daarin het verzoek iets uit te voeren.

  • Als Zorggebruiker wil ik in mijn PGO in het kader van een behandeling verzoeken van een Zorgverlener om bepaalde taken uit te voeren ontvangen.

Beleidsuitgangspunten

  1. Er wordt zoveel mogelijk gebruikgemaakt van de al bestaande MedMij functionaliteiten en gegevensdiensten.

  2. DVP’s moeten workflow implementeren, zodat zij allen notificaties en taken kunnen verwerken.

  3. DVA’s mogen workflow implementeren en moeten dit kenbaar maken aan het netwerk.

  4. Authenticatie en langdurige toestemming zijn van toepassing op de MVP voor workflow.

  5. Naast de gegevensuitwisseling moet ook het gebruik van modules mogelijk zijn vanuit workflow.

  6. Er wordt gebruikgemaakt van bestaande, internationale standaarden.

Architectuurdrijfveren

  1. Voor monitoring-doeleinden wordt logging ingebouwd in het proces.

  2. Beveiliging van en veiligheid binnen het MedMij netwerk blijft hoog.

  3. Zorgen dat de deelnemers niet geconfronteerd met teveel verschillende oplossingen/mogelijkheden voor het starten en uitvoeren van workflows.

  4. Authenticatie, autorisatie, patiënttoestemming en lokalisatie worden in de toekomst zorgbreed ingevuld. Hiermee moet rekening worden gehouden in de uitwerking.

  5. Zorgen dat de modellen/architectuur (in EA) worden toegevoegd of bijgewerkt op basis van wat ontworpen is.

Referentiearchitecturen

Architectuurprincipes

Organisatiebeleid

  • De rol van Procesbeheerder wordt toegekend aan de Zorgaanbieder. De Zorgaanbieder vult deze rol zelf in, bijvoorbeeld vanuit zijn interne processen.

Zorgproces

  • Workflows bestaan uit enkelvoudige taken. Dit wil zeggen dat de Zorgverlener per workflow één taak aan een Zorggebruiker kan toewijzen.

  • Taken van de zorgaanbieder voor de zorggebruiker kunnen op verschillende manieren bij de PGO bekend worden:

    • Gebruikmakend van de functie verzamelen kan een Zorggebruiker de aan de Zorggebruiker toegekende taken laten ophalen.

    • Vanuit een abonnement op taken worden notificaties gestuurd naar de PGO die het abonnement heeft afgesloten. De PGO haalt op basis van een gebruikersactie of de toestemming voor automatische gegevensuitwisseling de taken ook daadwerkelijk op. Hiervoor wordt dan weer gebruikgemaakt van de hiervoor genoemde gegevensdienst.

  • Taken worden alleen uitgewisseld als deze bijdragen aan een verbetering/versnelling van het zorgproces.

  • De rol van procesbeheerder is altijd de zorgaanbieder. Hiermee liggen regie en verantwoordelijkheid altijd bij de zorgaanbieder, ook op het moment dat een proces wordt geïnitieerd door de zorggebruiker.

Informatie

  • Taken moeten kunnen worden verzameld. Hiervoor moet een gegevensdienst worden ontwikkeld en beheerd.

  • Er wordt zoveel als mogelijk gebruikgemaakt van standaarden uit het domein zorg, zoals FHIR.

Applicatie

  • Er wordt zoveel als mogelijk gebruikgemaakt van standaarden uit het domein zorg, zoals FHIR. Binnen het onderwerp Workflow betekent dit dat onder andere gekeken moet worden naar

    • Activity definitions

    • Tasks

    • Subscriptions

    • Assertions

IT-infrastructuur

Afhankelijkheden

Qua interne onderwerpen

De MVP is nauwelijks afhankelijk van externe onderwerpen. Met het oog op de toekomst moet wel rekening worden gehouden met de gewenste afhankelijkheden. Te noemen zijn bijvoorbeeld de generieke diensten ‘Vertrouwde authenticatie', ‘Toestemmingsregister’ en 'Lokalisatiedienst’.

Relaties met andere projecten

  • De alpha fase voor de MVP voor Modules moetzijn afgerond, zodat taken binnen deze MVP de volgende functies kunnen omvatten:

    • Gegevens verzamelen

    • Gegevens delen

    • Uitvoeren van een module

Oplossingsrichting(en)

Voor abonneren moet gekeken worden welke wijzigingen in het afsprakenstelsel nodig zijn om de FHIR variant te implementeren. Zie https://fhir-ru.github.io/subscription.html, zoals bijvoorbeeld ook binnen Koppeltaal gebruikt wordt. Daarnaast moet ook voor Workflow zoveel als mogelijk worden aangesloten bij de oplossing die binnen Koppeltaal is neergezet.

Architectuurrisicoanalyse

Nr

Beschrijving

Conclusie

1

Project overstijgende ontwerpkeuzes

-

Architectuurafwijkingen

  1. Bij abonneren wordt in de huidige vorm (afsprakenstelsel versie 2) gebruikgemaakt van door MedMij samengestelde JSON berichten. De wens is geuit om binnen de zorg hiervoor gebruik te maken van FHIR abonnementen. Onderzocht moet worden wat de voordelen en nadelen zijn en of een afwijking van de huidige architectuur voldoende van waarde is.

Fasering

Minimum Viable Product (MVP)

Bij het minimum viable product gaat het alleen om het werkend krijgen van de modules, zonder rekening te houden met afhankelijkheden. Het MVP moet zo snel mogelijk opgeleverd kunnen worden, waarbij vooral gebruikgemaakt wordt van zaken die nu al aanwezig zijn. Dit betekent dat bijvoorbeeld gebruiksvriendelijkheid nog niet wordt geoptimaliseerd. Het MVP wordt hoogstwaarschijnlijk ook nooit gepubliceerd.

Scopebepaling

In scope

  • Abonneren op taken door de Zorggebruiker (PGO) bij de Zorgaanbieder (DVA)

  • Workflow starten door taak aan te maken

  • Taken van de Zorgverlener voor de Zorggebruiker

    • Notificeren van klaarstaande taken door DVA aan PGO en daarmee de Zorggebruiker

    • Verzamelen van taken door de PGO

    • Uitvoeren van taken

    • Delen van resultaat met de DVA en daarmee met de Zorgaanbieder en Zorgverlener

  • Taken van de Zorggebruiker voor de Zorgaanbieder

    • Delen van de taak met de DVA door de PGO

    • Notificeren van de klaarstaande resultaten dor de DVA aan de PGO en daarmee de Zorggebruiker

    • Verzamelen van de resultaten door de PGO

Dit alles wordt uitgevoerd met de al beschikbare functies. Taken kunnen bestaat uit het ophalen van gegevens, het delen van gegevens en het uitvoeren van een module.

Buiten scope

  • Herhalende en gelaagde taken

  • Generieke functies

    • Vertrouwde authenticatie

    • Toestemmingen

    • Lokalisatie

  • Machtigingen / vertegenwoordiging

  • Workflows met meerdere (achtereenvolgende) taken

  • Bij Zorgaanbieders aanwezige workflow-oplossingen

  • Discovery

  • Herinneringsnotificatie sturen naar Persoon

  • Vraagfunctie bij taken in de vorm van chat

  • Inhoudelijk wijzigen van taken (dit wordt vormgegeven met het verwijderen van de bestaande en het uitgeven van een nieuwe taak)

Afgeleide functionele usecases

Zorgverlener

  1. Als Zorgverlener wil ik per keer één taak aan een Zorggebruiker kunnen toewijzen.

  2. Als Zorgverlener wil ik de Zorggebruiker notificeren dat er één of meerdere taken klaarstaan (abonnement).

  3. Als Zorgverlener wil ik een uitgegeven taak kunnen intrekken / annuleren.

  4. Als Zorgverlener wil ik genotificeerd worden over een statuswijziging, dus ook bij het afwijzen van een taak door de Zorggebruiker.

  5. Als Zorgverlener wil ik de uiterste datum aan kunnen geven dat de taak uitgevoerd moet worden.

  6. Als Zorgverlener wil ik (meervoudige) resultaten kunnen ontvangen op één taak.

Zorggebruiker

  1. Als Zorggebruiker wil ik taken kunnen verzamelen door op een knop drukken.

  2. Als Zorggebruiker wil ik aangeven dat ik van mijn Zorgverlener notificaties wil ontvangen over taken.

  3. Als Zorggebruiker wil ik een bericht ontvangen op het moment dat er één of meerdere taken klaar staan in mijn PGO.

  4. Als Zorggebruiker wil ik (meervoudige) resultaten kunnen versturen naar de Zorgverlener, gebaseerd op één taak.

  5. Als Zorggebruiker wil ik een aan mij toegewezen taak kunnen uitvoeren.

  6. Als Zorggebruiker wil ik een aan mij toegewezen toegewezen taak kunnen afwijzen.

  7. Als Zorggebruiker wil ik de historie van mijn taken inzien (levenslang).

MedMij Beheer

  1. Als MedMij Beheer wil ik een lijst beschikbaar hebben met alle workflow-profielen (zie koppeltaal).

  2. Als MedMij Beheer wil ik deelnemers kunnen kwalificeren op de ondersteuning van workflow-profielen.

  3. Als MedMij Beheer wil ik partijen kunnen accepteren voor de functie Workflow ( o.a. security, juridisch, R&A).

  4. Als MedMij Beheer wil ik het gebruik van Workflows kunnen monitoren.

Volgende fasen

Door afhankelijkheden met externe projecten kan volgorde in de volgende fasen niet bepaald worden.

  • Toevoegen van het gebruik van Vertrouwde authenticatie en Machtigingen (Afhankelijkheid implementatie VWS)

  • Toevoegen van het gebruik van Toestemmingsregister (Afhankelijkheid implementatie Mitz / VZVZ)

  • Toevoegen van het gebruik van Lokalisatieregister (Afhankelijkheid implementatie Mitz / VZVZ)

  • Toevoegen van het gebruik van Discovery

  • Toevoegen van het gebruik van workflows met meerdere taken

Table of Contents
minLevel1
maxLevel6
include
outlinefalse
indent
stylenone
exclude
typelist
class
printabletrue