Skip to end of banner
Go to start of banner

PSA Workflow (MVP, taken)

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 5 Next »

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.

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

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

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

3. Scope

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

3.2. Buiten scope

  • Herhalende en gelaagde taken

  • Generieke functies

    • Vertrouwde authenticatie

    • Toestemmingen

    • Lokalisatie

  • Machtigingen / vertegenwoordiging

  • Workflows met meerdere (achtereenvolgende) taken.

  • Bij Zorgaanbieders aanwezige workflow-oplossingen.

4. Betrokken architecten

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

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

7. Referentiearchitecturen

8. Architectuurprincipes

8.1. Organisatiebeleid

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

8.3. Informatie

  • Er wordt zoveel als mogelijk gebruikgemaakt van FHIR.

8.4. Applicatie

8.5. IT-infrastructuur

9. Afhankelijkheden

10. Relaties met andere projecten

11. Oplossingsrichting(en)

12. Architectuurrisicoanalyse

13. Project overstijgende ontwerpkeuzes

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

  • No labels