Versions Compared

Old Version 3

changes.mady.by.user Casper van der Harst

Saved on

compared with

New Version 4

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

Stakeholderanalyse

Idee

Vooronderzoek

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

Acceptatie

C

C

C

C

C

Proves

I

A

I

A

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

  • (Lead architect)

  • (Solution architect)

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

Zorgproces

  • Taken van de zorgaanbieder voor de zorggebruiker kunnen op verschillende manier

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

Informatie

  • Er wordt zoveel als mogelijk gebruikgemaakt van FHIR.

Applicatie

IT-infrastructuur

Afhankelijkheden

Relaties met andere projecten

Oplossingsrichting(en)

Architectuurrisicoanalyse

Project overstijgende ontwerpkeuzes

Architectuurafwijkingen

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