Workflow: Rollen, Functies, verantwoordelijkheden

Extensie Workflow

Verantwoordelijkheden, Workflow

Workflow komt als nieuwe functie binnen het Afsprakenstelsel en komt hiermee naast de bestaande functies te staan. De functie Workflow is derhalve een extensie. De verantwoordelijkheden die in de MedMij Core staan beschreven, zijn ook van toepassing op deze extensie. Daarnaast gelden de hieronder (vervangende) verantwoordelijkheden.

Rollen

Workflow Server

De verantwoordelijkheden die in de MedMij Core staan beschreven, zijn ook van toepassing op deze extensie. Daarnaast gelden de hieronder (vervangende) verantwoordelijkheden.

De MedMij Core beschrijft rol Resource Server. Nauw gerelateerd aan deze rol beschrijft deze extensie de rol Workflow Server.

Waar een Persoon zelf operationeel betrokken wordt in het informatieverkeer — namelijk om zich te laten authenticeren, en het verkeer te laten autoriseren — laat de Aanbieder zich operationeel geheel vertegenwoordigen door zijn Dienstverlener en diens Authorization Server, Resource Server en Workflow Server. Ook al zal in veel gevallen de gezondheidsinformatie (taken en procedures) uiteindelijk uit een achterliggend systeem worden betrokken, is dat voor het MedMij Afsprakenstelsel geen kwestie. Het is voldoende om bij de Authorization Server, Resource Server en Workflow Server de eindverantwoordelijkheid neer te leggen (black box).

De functie Workflow gebruikt een generiek FHIR R4B profiel http://hl7.org/fhir/R4B/index.html.

Hieronder volgt een overzicht van de belangrijkste verantwoordelijkheden die de Workflow Server heeft om workflows goed te kunnen hanteren.

1. CRUD Operations (Create, Read, Update, Delete)

2. Search Capabilities

3. History Interaction: de server moet versiebeheer ondersteunen zodat eerdere versies kunnen worden opgehaald.

4. Workflow Operations: de server moet in staat zijn om de $apply operation te ondersteunen, waarmee een ActivityDefinition kan worden toegepast op een specifieke context, wat resulteert in de aanmaak van gerelateerde resources zoals Task.

5. Transaction Bundles: dit type bundle wordt vaak gebruikt bij het batchgewijs aanmaken, bijwerken of verwijderen van resources, zoals het tegelijkertijd aanmaken van een patiënt, een taak en een afspraak.

6. CapabilityStatement (Server Metadata): Deze FHIR Resource beschrijft welke operaties en zoekparameters de server ondersteunt, inclusief eventuele beperkingen.

7. Security and Authorization: de server moet beveiliging en autorisatie ondersteunen, zodat alleen geautoriseerde gebruikers toegang hebben tot het aanmaken, lezen, bijwerken, en verwijderen van resources.

Workflow rollen

Een workflow beschrijft werk dat wordt uitgevoerd door iets of iemand, en bestaat uit één of meerdere taken. In deze eerste fase van de functie Workflow bestaat workflow uit 1 taak. Een workflow kent altijd één aanvrager en één procesbeheerder. Een taak kent altijd één uitvoerder.

Definitie van de rollen:

Om als Persoon te kunnen deelnemen aan workflows zijn een aantal nieuwe interacties nodig in het MedMij afsprakenstelsel:

1. Binnen de Dienstverlener Aanbieder maakt een Zorgaanbieder [Aanvrager] een taak voor een bepaalde Persoon [Uitvoerder];

2. Persoon [Uitvoerder] wijzigt een bestaande taak (bijvoorbeeld de status ervan, of de uitkomst ervan), bij een Dienstverlener Aanbieder [Procesbeheerder];

3. Persoon zoekt, bij een Dienstverlener Aanbieder [Procesbeheerder], naar voor haar relevante taken.

Functies en gegevens, Workflow

Op deze pagina staan de diagrammen behorende bij de functie Workflow. De diagrammen tonen allereerst de situatie waarin alle acties slagen tot en met het uiteindelijke voltooien van een taak en inzien van de resultaten (de zogenaamde happy flow). De oranje banen horen bij het Persoonsdomein, de blauwe bij het Aanbiedersdomein. De grijze banen vallen buiten het MedMij afsprakenstelsel.

Businesslaag

Er zijn verschillende betrokken rollen, namelijk: de Persoon in workflowrol Uitvoerder, de Dienstverlener Persoon (DVP), de Dienstverlener Aanbieder (DVA) in workflowrol Procesbeheerder, en de Zorgaanbieder in workflowrol Aanvrager.

Persoon (Uitvoerder)

De workflow begint met de Uitvoerder, die eerst een abonnement aanmaakt als voorwaarde om taken en notificaties te kunnen ontvangen. Nadat dit abonnement is ingesteld, kan de uitvoerder een taak ophalen, accepteren en vervolgens uitvoeren. Na de uitvoering wordt de taak voltooid. Gedurende dit proces ontvangt de uitvoerder notificaties, die hij/zij kan bekijken en verwerken. Deze interactie wordt gefaciliteerd door de DVP.

Dienstverlener Persoon

De DVP faciliteert de communicatie tussen de Uitvoerder en de technische processen. De DVP verzorgt onder andere het tonen van notificaties en de verwerking daarvan. De Uitvoerder krijgt zo meldingen over de nieuwe en gewijzigde taken en kan deze verwerken via de DVP. Optioneel kan de DVP notificaties opslaan in het dossier.

Dienstverlener Aanbieder (Procesbeheerder)

De DVA is verantwoordelijk voor het beheer van Taken binnen de Workflow. De DVA slaat taken op en zorgt ervoor dat notificaties worden verzonden naar de relevante partijen, zoals de Aanvrager en/of de Uitvoerder. Deze Procesbeheerder zorgt voor een correcte registratie en verwerking van de verschillende stappen binnen het taakbeheer.

Zorgaanbieder (Aanvrager)

De Zorgaanbieder begint de workflow door een taak aan te maken of een bestaande taak te wijzigen. Vervolgens kan de Zorgaanbieder de voortgang van de taak volgen en ontvangt hij/zij notificaties over de uitvoering van de taak. Zodra de taak is voltooid, kan de zorgaanbieder de resultaten inzien. Deze rol valt buiten het Afsprakenstelsel.

Uitzonderingen op de Happy flow van de functie Workflow

In onderstaande tabel staan de uitzonderingssituaties beschreven bovenop de reeds beschreven uitzonderingssituaties in het afsprakenstelsel. Alle worden door de Dienstverlener aanbieder in zijn workflow rol als Procesbeheerder ontdekt.

Implementatie van de use cases onder Workflow

De nieuwe functie Workflow behelst het aanmaken van een Taak door een zorgaanbieder. Het afsprakenstelsel beschrijft niet hoe dit proces bij een zorgaanbieder dient te verlopen. In onderstaand diagram beschrijven we - voor de volledigheid - wel alle stappen.

De eerste twee stappen zijn illustratief om een taak te maken inclusief een procedure. Deze stappen verschillen per zorgaanbieder en kunnen er als volgt uit zien:

1. Zorgaanbieder selecteert een ActivityDefinition en maakt een Taak aan

   1. Een Zorgaanbieder kiest een vooraf gedefinieerde ActivityDefinition. Dit is een gestructureerde beschrijving van een activiteit, zoals een vragenlijst of een zelfmetingprotocol. Deze ActivityDefinition bevat alle benodigde informatie over de activiteit, zoals instructies, protocollen, en de benodigde middelen.

   2. Zodra de ActivityDefinition is geselecteerd, wordt er een Task aangemaakt. Deze taak is specifiek gericht op de uitvoering van de activiteit zoals gedefinieerd in de ActivityDefinition. De Task bevat referenties naar de ActivityDefinition, en details zoals wie de taak uitvoert, op welke Persoon de taak betrekking heeft, en wanneer de taak moet worden uitgevoerd.

2. Taak opslaan op de Workflow Server

   1. De aangemaakte taak wordt verzonden naar en opgeslagen op de Workflow Server. Dit stelt andere systemen in staat om de taak te zien en erop te reageren.

Stappen 3 tot en met 11 zijn optioneel:

3. De Workflow Server informeert de Subscription Server over de nieuwe/gewijzigde Taak.

4. De Subscription Server doet een abonnementscheck om te controleren of er abonnementen actief zijn.

5. De Subscription Server kijkt bij de gevonden abonnementen of de wijziging in de Resource overeenkomt met de abonnementscriteria.

6. De Subscription Server stuurt een notificatie naar de Notification Client van de DVP. (Wanneer er een abonnement is, en de wijziging aan de criteria voldoet)

7. De Notification Client stuurt de notificatie door naar de DVP Server.

8. De DVP Server slaat de notificatie op in het dossier.

9. De DVP Server stuurt de notificatie door naar de User Agent.

10. De User Agent toont de notificatie aan de Persoon.

11. De Persoon opent de notificatie in de User Agent.

Stappen 12 tot en met 23 zijn niet optioneel:

12. De Persoon doet in zijn Workflow rol als Uitvoerder het verzoek om taken op te halen in de User Agent.

13. De User Agent haalt namens de Persoon de Taken op uit de DVP Server. Dit verzoek kan resulteren in 2 scenario’s.

Scenario 1:

14. Wanneer de Taak opgeslagen is in het dossier, wordt deze direct opgehaald uit het dossier door de DVP Server.

Scenario 2:

15. Wanneer er geen Taak is opgeslagen in het dossier van de DVP Server, haalt de DVP Server de Taak op uit de Workflow Server.

16. De Workflow Server stuurt het resultaat (de Taak) op naar de DVP Server.

17. De DVP Server stuurt de opgehaalde Taak door naar de User Agent.

18. De User Agent toont de Taak aan de Persoon.

19. De Persoon bekijkt de Taak in de User Agent.

20. De Persoon selecteert de Taak in de User Agent.

21. De Persoon wijzigt de Taak in de User Agent.

22. De User Agent stuurt een update van de taakwijziging naar de DVP Server.

23. De DVP Server slaat de Taak op in de Workflow Server.

Na het opslaan van de Taak (wijziging) kunnen de geabonneerden genotificeerd worden. Deze stappen vallen buiten het Afsprakenstelsel en kunnen er als volgt uit zien:

24. De Workflow Server informeert de Subscription Server over de gewijzigde Taak.

25. De Subscription Server doet een abonnementscheck om te controleren of er abonnementen actief zijn.

26. De Subscription Server kijkt bij de gevonden abonnementen of de wijziging in de Resource overeenkomt met de abonnementscriteria.

MedMij Catalogus (Lijsten)

Binnen Fase 1 is alleen de verkenning gedaan, de daadwerkelijke uitwerking wordt binnen Fase 2 gedaan.

Voor het delen van resultaten voortvloeiend uit een Taak zijn de volgende gegevensdiensten en functies van toepassing.

Verantwoordelijkheden

Om als Persoon te kunnen deelnemen aan workflows zijn een aantal nieuwe interacties nodig in het MedMij afsprakenstelsel:

1. Persoon wijzigt een bestaande taak (bijvoorbeeld de status ervan), bij een Procesbeheerder;

2. Persoon zoekt, bij een Procesbeheerder, naar voor haar relevante taken.

De Persoon heeft derhalve toegang nodig tot de FHIR Task Resource op de Workflow Server van de Procesbeheerder. Deze Task Resource kan ook opgeslagen worden door de Dienstverlener Persoon op de DVP server.

Taken (Task Resources) worden gebaseerd op een generiek patroon. Voor deze taken komt een generiek FHIR R4B profiel http://hl7.org/fhir/R4B/index.html.

De Persoon kan de vereiste interacties vervolgens middels een FHIR-create, een FHIR-read, een FHIR-update, of een FHIR-search uitvoeren via de DVP van de PGO. Dit verloopt analoog aan de bestaande werkwijze voor verzamelen en delen.

Task interface, Workflow

Het afsprakenstelsel specificeert de inhoud van de Task Resource om interoperabiliteit te garanderen.

De volgende attributen kunnen aanwezig zijn in een Task Resource en de attributen met een * zijn verplicht. In een latere versie bekijken we of hoe dit beschreven gaat worden naar het afsprakenstelsel.

Let op, deze lijst is niet-uitputtend, de FHIR specificatie kent nog meer attributen (bijvoorbeeld basedOn, for). Eventuele resource referenties kunnen door de DVP opgehaald worden bij de DVA. Deze stap is niet beschreven in de use cases.

Voorbeeld van een Task resource:

{
  "resourceType": "Task",
  "id": "task-001",
  "intent": "order",
  "status": "requested",
  "instantiatesCanonical": "http://example.org/fhir/ActivityDefinition/zelfmeting-bloeddruk",
  "instantiatesUri": "http://example.org/fhir/services/gegevensdienst/123456",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2024-08-21T08:00:00Z",
    "source": "12345"  // Dit is een referentie naar de eigenaar die de wijziging heeft aangebracht
    "tag": ""
  }
  "code": {
    "coding": [
      {
        "system": "http://example.org/fhir/TaskType",
        "code": "blood-pressure-monitoring",
        "display": "Bloeddrukmeting"
      }
    ],
    "text": "Bloeddrukmeting"
  },
  "owner": {
    "reference": "Patient/12345",
    "identifier": {
      "system": "urn:oid:2.16.840.1.113883.2.4.6.3",
      "value": "123456789"
    },
    "display": "Jan Jansen"
  },
  "requester": {
    "reference": "Organization/MedMijAanbieder",
    "display": "MedMij Aanbiedernaam"
  },
  "description": "Deze taak betreft het dagelijks uitvoeren van een bloeddrukmeting.",
  "restriction": {
    "period": {
      "start": "2024-08-21T08:00:00+01:00",
      "end": "2024-08-28T08:00:00+01:00"
    }
  },
  "note": [
    {
      "text": "De patiënt moet de bloeddrukmeting 's ochtends voor het ontbijt uitvoeren."
    }
  ]
}

Status van een taak

Om de integriteit van een taak te kunnen borgen is de status van een taak onderhevig aan een ‘state’ model. In het onderstaande diagram wordt weergegeven welke status een taak kan krijgen en wie deze status aan een taak kan toewijzen.

Bijvoorbeeld:

• een aanvrager dient de taak op ‘requested' te zetten

• een aanvrager mag altijd de taak naar ‘entered-in-error’ zetten

• een uitvoerder dient de taak opvolgend naar received, accepted of rejected zetten

• een uitvoerder dient de taak vanuit accepted naar in-progres zetten

• Enzovoorts.

Afbeelding: ‘state’-model diagram

Schermen (User interface), Workflow

In Fase 2 (versie 0.8) komen er voorstellen voor de user interface betreffende de nieuwe functie Workflow.