imm:Landingspagina Vaccinatie Immunisatie: verschil tussen versies
Regel 10: | Regel 10: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Doelgroep== | ==Doelgroep== | ||
Regel 28: | Regel 22: | ||
==Kaders & Uitgangspunten== | ==Kaders & Uitgangspunten== | ||
+ | |||
+ | ==Context en scope== | ||
+ | In de informatiestandaard Immunisatie is dit functioneel ontwerp gericht op de scope vaccinatie-informatie. Hiermee is overige informatie rond immunisatie zoals natuurlijke immunisatie-informatie (doorgemaakte infectie/ziekte) en testresultaten op dit moment expliciet buiten scope. | ||
+ | In de [https://www.urlvandewebsitewaarderroadmapmoetkomen.nl/: roadmap Immunisatie] kan het beheer- en (door)ontwikkelplan worden gevonden voor de informatiestandaard, uitbreidingen en toekomstige doorontwikkelingen worden hierin beschreven in samenwerking met de stakeholders. | ||
+ | |||
+ | Het proces voor informatie-uitwisseling voor vaccinatie-informatie is in onderstaande afbeelding gevisualiseerd: | ||
+ | |||
+ | PLAATJE UITLEG --> HIERBIJ SPLIT TUSSEN EERSTE OPLEVERING EN UITEINDELIJKE BREDE SCOPE. BESCHRIJVEN DAT EERSTE USE CASE OPLEVERING DE UITWISSELING VAN XIS NAAR PGO'S IN MEDMIJ CONTEXT IS. TEVENS PIJLEN AANPASSEN | ||
+ | |||
+ | [[Image:Procesplaat Vaccinaties uitwisseling.jpg|Gegevensuitwisseling Vaccinaties]] | ||
+ | |||
+ | ''<span style="color:#D2691E"> Figuur: Proces uitwisseling vaccinatieinformatie </span>'' | ||
+ | |||
===Richtlijn en proces=== | ===Richtlijn en proces=== | ||
Regel 72: | Regel 79: | ||
Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR. Wanneer verschillende use cases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces. In dit functioneel ontwerp wordt elke use case geanalyseerd en uitgewerkt. | Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR. Wanneer verschillende use cases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces. In dit functioneel ontwerp wordt elke use case geanalyseerd en uitgewerkt. | ||
− | == | + | ==Use case 1== |
− | + | *Usecase 1 betreft het beschikbaarstellen en raadplegen van een vaccinatie ten behoeve van een PGO (Persoonlijke Gezondheids Omgeving) (PULL); | |
− | |||
− | |||
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Verwijzen naar MedMij patiënt use case, pagina nog aan laten maken inclusief duidelijkheid onder welke versie/release de use case komt. | |
− | + | https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpImmunisatie#Use_case:_Raadplegen_vaccinatieinformatie_in_persoonlijke_gezondheidsomgeving | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ==Use case 2== | |
− | + | *Usecase 2 betreft het beschikbaarstellen en raadplegen van alle bekende vaccinaties ten behoeve van een PGO (Persoonlijke Gezondheids Omgeving) (PULL); | |
− | |||
− | |||
− | == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Verwijzen naar MedMij patiënt use case, pagina nog aan laten maken inclusief duidelijkheid onder welke versie/release de use case komt. | Verwijzen naar MedMij patiënt use case, pagina nog aan laten maken inclusief duidelijkheid onder welke versie/release de use case komt. | ||
Regel 210: | Regel 139: | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
====Systemen & Systeemrollen==== | ====Systemen & Systeemrollen==== |
Versie van 9 nov 2021 00:14
1 Inleiding
1.1 Algemeen
Deze pagina beschrijft het functioneel ontwerp voor de informatiestandaard Immunisatie. Het functioneel ontwerp beschrijft voor alle uitwisselscenario's (in dit document use cases genoemd) uit de informatiestandaard de transacties, transactiegroepen, de systemen, de systeemrollen en de bedrijfsrollen van zorgverleners/zorgaanbieders, publieke gezondheidsorganisaties of patiënten/burgers. Daarvoor worden de eisen aangegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 wordt verder ingegaan op wat een use case inhoudt. Per use case zijn de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de Nictiz webpagina voor informatiestandaarden. Voor de verklaring van de begrippen die voorkomen in het functioneel ontwerp wordt verwezen naar het begrippenoverzicht op de Nictiz website.
1.2 Doelgroep
De doelgroepen van dit functionele ontwerp zijn:
- Productmanagers, architecten, ontwerpers en testers van XIS-leveranciers, zorgorganisaties, publieke gezondheidsorganisaties en Nictiz;
- Zorgverleners en hun vertegenwoordigers;
- Patiënten/burgers
1.3 Kaders & Uitgangspunten
1.4 Context en scope
In de informatiestandaard Immunisatie is dit functioneel ontwerp gericht op de scope vaccinatie-informatie. Hiermee is overige informatie rond immunisatie zoals natuurlijke immunisatie-informatie (doorgemaakte infectie/ziekte) en testresultaten op dit moment expliciet buiten scope. In de roadmap Immunisatie kan het beheer- en (door)ontwikkelplan worden gevonden voor de informatiestandaard, uitbreidingen en toekomstige doorontwikkelingen worden hierin beschreven in samenwerking met de stakeholders.
Het proces voor informatie-uitwisseling voor vaccinatie-informatie is in onderstaande afbeelding gevisualiseerd:
PLAATJE UITLEG --> HIERBIJ SPLIT TUSSEN EERSTE OPLEVERING EN UITEINDELIJKE BREDE SCOPE. BESCHRIJVEN DAT EERSTE USE CASE OPLEVERING DE UITWISSELING VAN XIS NAAR PGO'S IN MEDMIJ CONTEXT IS. TEVENS PIJLEN AANPASSEN
Figuur: Proces uitwisseling vaccinatieinformatie
1.4.1 Richtlijn en proces
1.4.1.1 Dossierverhuisbericht
De NHG richtlijn Informatieverstrekking tussen huisartsen bij overdracht van behandelrelatie (NHG richtlijn Dossierverhuisbericht) beschrijft de processen en informatie-uitwisseling tussen de oude en de nieuwe huisarts.
1.4.1.2 Waarneembericht
De NHG Richtlijn Gegevensuitwisseling huisarts en Centrale Huisartsenpost (CHP) (NHG richtlijn Waarneembericht) beschrijft de processen en informatie-uitwisseling tussen de huisarts en de HAP.
1.4.1.3 Verwijzing huisarts naar medisch specialist
De NHG richtlijn Informatie-uitwisseling tussen huisarts en medisch specialist (NHG richtlijn HASP) beschrijft de processen en informatie-uitwisseling tussen de huisarts en de medisch specialist.
1.4.1.4 Verwijzing huisarts naar paramedicus
De NHG richtlijn Informatie-uitwisseling tussen arts en paramedicus (NHG richtlijn HASP-paramedicus) beschrijft de processen en informatie-uitwisseling tussen de huisarts en de paramedicus.
1.4.1.5 Verwijzing huisarts naar GGZ
De NHG-Richtlijn Informatie-uitwisseling huisarts - tweedelijns GGZ (NHG richtlijn HASP-GGZ) beschrijft de processen en informatie-uitwisseling tussen de huisarts en de GGZ.
1.4.1.6 Ketenzorg
De ketenzorgoverdracht is gebaseerd op de volgende zorgstandaardaarden:
- zorgstandaard Diabetes;
- zorgstandaard COPD;
- zorgstandaard CVRM.
1.4.1.7 Patiënten overdrachten
De NHG-Richtlijn Online inzage in het H-EPD door patiënt (NHG richtlijn H-EPD Patiënt) beschrijft de processen en informatie-uitwisseling tussen de huisarts en de patiënt.
1.4.2 Reikwijdte Informatiestandaard
De reikwijdte van de informatiestandaard beslaat de functionele beschrijvingen en de dataset voor alle gegevensuitwisselingen binnen één of meerdere zorgprocessen.
1.4.3 Infrastructuur
De specificatie van de infrastructuur waarover berichten worden uitgewisseld valt buiten de scope van deze informatiestandaard.
1.5 Kwalificatie
Op basis van dit functioneel ontwerp en de daarbij behorende dataset wordt een kwalificatiescript opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit functioneel ontwerp. Voor meer informatie zie de websitepagina over Nictiz kwalificaties.
2 Use case(s)
Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR. Wanneer verschillende use cases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces. In dit functioneel ontwerp wordt elke use case geanalyseerd en uitgewerkt.
2.1 Use case 1
- Usecase 1 betreft het beschikbaarstellen en raadplegen van een vaccinatie ten behoeve van een PGO (Persoonlijke Gezondheids Omgeving) (PULL);
Verwijzen naar MedMij patiënt use case, pagina nog aan laten maken inclusief duidelijkheid onder welke versie/release de use case komt. https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpImmunisatie#Use_case:_Raadplegen_vaccinatieinformatie_in_persoonlijke_gezondheidsomgeving
2.2 Use case 2
- Usecase 2 betreft het beschikbaarstellen en raadplegen van alle bekende vaccinaties ten behoeve van een PGO (Persoonlijke Gezondheids Omgeving) (PULL);
Verwijzen naar MedMij patiënt use case, pagina nog aan laten maken inclusief duidelijkheid onder welke versie/release de use case komt. https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpImmunisatie#Use_case:_Raadplegen_vaccinatieinformatie_in_persoonlijke_gezondheidsomgeving
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.2.1 Doel en Relevantie
2.2.2 Proces en Context (pre- en postproces)
2.2.2.1 Preproces
2.2.2.2 Proces
2.2.2.3 Postproces
2.2.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.2.4 Informatieoverdracht
2.2.4.1 Systemen & Systeemrollen
2.2.4.2 Transacties & Transactiegroepen
2.2.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.2.4.4 Systemen & Systeemrollen
De huisarts en de paramedicus maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (EPD's of ECD's). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de verwijzing naar de medisch specialist mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Verwijsbericht Huisarts naar Paramedicus Sturend Systeem | [HZP-VPS] | Sturen verwijzing van de huisarts naar de paramedicus |
EPD's of ECD's | Huisartsen Zorg Proces - Verwijsbericht huisarts naar Paramedicus Ontvangend systeem | [HZP-VPO] | Ontvangen verwijzing van de huisarts door de paramedicus |
Zie ook onderstaande afbeelding:
2.2.4.5 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen verwijzing (PUSH) | Sturen verwijzing | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen verwijzing |
2.2.4.6 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de verwijzing door de huisarts naar de paramedicus:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Huisarts verwijst naar paramedicus | Sturen verwijzing(PUSH) | Sturen verwijzing door huisarts aan paramedicus | [HZP-VPS] | HIS | Huisarts |
2.3 Use case: Paramedicus stuurt directe toegang (DT) aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.3.1 Doel en Relevantie
De paramedicus stuurt altijd een bericht directe toegang:
- Na een eerste contact met de patiënt bij directe toegang
- Als de patiënt na eerdere afronding van de behandeling terugkomt voor dezelfde klacht
Een reden om hiervan af te wijken is dat de patiënt expliciet bezwaar maakt tegen berichtgeving aan de huisarts en de paramedicus erin mee kan gaan deze berichtgeving achterwege te laten.
Met het bericht directe toegang met behandeling wordt de verantwoordelijkheid van zorg voor de patiënt overgedragen aan de paramedicus. Bij directe toegang zonder behandeling blijft de verantwoordelijkheid van zorg bij de arts.
2.3.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht directe toegang stuurt:
- na een eerste contact met de patiënt bij directe toegang
- als de patiënt na eerdere afronding van de behandeling terugkomt voor dezelfde klacht
Een reden om hiervan af te wijken is dat de patiënt expliciet bezwaar maakt tegen berichtgeving aan de huisarts en de paramedicus erin mee kan gaan deze berichtgeving achterwege te laten.
2.3.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een bericht directe toegang van de paramedicus aan de huisarts.
2.3.2.2 Proces
Het proces van deze use case is:
- De paramedicus stuurt een bericht directe toegang aan de huisarts
- De huisarts ontvangt een bericht directe toegang
2.3.2.3 Postproces
Er zijn geen post condities of voorwaarden van toepassing voor het sturen van een bericht directe toegang van de paramedicus aan de huisarts.
2.3.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Paramedicus | De paramedicus stuurt een bericht directe toegang |
Huisarts | De huisarts ontvangt een bericht directe toegang |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.3.4 Informatieoverdracht
Zowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- EPD's of ECD's (informatiesystemen voor paramedici).
2.3.4.1 Systemen & Systeemrollen
De paramedicus en de huisarts maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (EPD's of ECD's). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het bericht directe toegang aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
EPD's of ECD's | Huisartsen Zorg Proces – DT Paramedicus naar huisarts sturend Systeem | [HZP-DPS] | Sturen bericht directe toegang door de paramedicus aan de huisarts |
HIS | Huisartsen Zorg Proces – DT Paramedicus naar Huisarts Ontvangend Systeem | [HZP-DPO] | Ontvangen bericht directe toegang van de paramedicus door de huisarts |
Zie ook onderstaande afbeelding:
2.3.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen bericht directe toegang (PUSH) | Sturen bericht directe toegang | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen bericht directe toegang |
2.3.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van sturen van het bericht directe toegang van de paramedicus aan de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Paramedicus stuurt bericht directe toegang aan huisarts | Sturen bericht directe toegang (PUSH) | Sturen bericht directe toegang door paramedicus aan huisarts | [HZP-DPS] | EPD of ECD | Paramedicus |
2.4 Use case: Huisarts stuurt update aan paramedicus
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.4.1 Doel en Relevantie
Deze use case beschrijft de reden van het versturen van een update door de huisarts aan de paramedicus. Een update volgt op de noodzaak om de continuïteit in de zorg te borgen. In dit bericht zitten de benodigde gegevens voor de paramedicus als het gaat om onverwachte bevindingen of gewijzigd beleid voor de patiënt met impact voor de zorg door de paramedicus.
2.4.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-paramedicus geeft aan dat de arts altijd een update stuurt:
- als antwoord op het verzoek om informatie door de paramedicus; dit kan ook het advies inhouden om de patiënt voor consultatie naar de arts te sturen (➞ informatieverstrekking)
- als de arts een vraag heeft aan de paramedicus (➞ informatieverzoek)
- bij overlijden van de patiënt
De arts overweegt een update:
- als zich een wijziging in het beloop voordoet, bij een andere gestelde diagnose en of wijziging van zorg aan de patiënt die van invloed is op de behandeling door de paramedicus
- bij een levensgebeurtenis
2.4.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van update van een huisarts naar een paramedicus.
2.4.2.2 Proces
Het proces van deze use case is:
- De huisarts stuurt een update naar paramedicus
- De update is beschikbaar in de tweede lijn op het moment van overname.
2.4.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van update van een huisarts naar een paramedicus.
2.4.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Huisarts | De huisarts stuurt een update |
Paramedicus | De paramedicus ontvangt update |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.4.4 Informatieoverdracht
Zowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem)
- EPD's of ECD's (informatiesystemen voor paramedici).
2.4.4.1 Systemen & Systeemrollen
De huisarts en de paramedicus maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (EPD's of ECD's). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de update aan de paramedicus mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Update Huisarts naar Paramedicus Sturend Systeem | [HZP-UPS] | Sturen update van de huisarts naar de paramedicus |
EPD's of ECD's | Huisartsen Zorg Proces – Update huisarts naar Paramedicus Ontvangend Systeem | [HZP-UPO] | Ontvangen update van de huisarts door de paramedicus |
Zie ook onderstaande afbeelding:
2.4.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen update (PUSH) | Sturen update | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen update |
2.4.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de update van de huisarts aan de paramedicus:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Huisarts stuurt update aan paramedicus | Sturen update (PUSH) | Sturen update door huisarts aan paramedicus | [HZP-UPS] | HIS | Huisarts |
2.5 Use case: Paramedicus stuurt update aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.5.1 Doel en Relevantie
Deze use case beschrijft de reden van het versturen van een update door de huisarts aan de paramedicus. Een update volgt op de noodzaak om de continuïteit in de zorg te borgen. In dit bericht zitten de benodigde gegevens voor de paramedicus als het gaat om onverwachte bevindingen of gewijzigd beleid voor de patiënt met impact voor de zorg door de paramedicus.
Bij (eenmalige) consultatie van de paramedicus blijft de verantwoordelijkheid voor de klacht/ zorgvraag bij de arts.
2.5.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een update stuurt:
- als antwoord op het verzoek om informatie door de arts (➞ informatieverstrekking)
- als antwoord op een consultatieaanvraag van de arts (➞ consultatieverslag)
De paramedicus overweegt een update:
- bij een eerste contact met de patiënt bij verwijzing (➞ update behandeling)
- als de paramedicus (meer) informatie nodig heeft van de huisarts (➞ informatieverzoek)
- als de patiënt lang onder behandeling blijft of bij afwijkend beloop: op gezette tijden rapportage over het ingezette traject (➞ update behandeling)
2.5.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een update van de paramedicus aan de huisarts.
2.5.2.2 Proces
Het proces van deze use case is:
- De paramedicus stuurt een update naar de huisarts
- Updates richting de verwijzer vinden plaats zo snel als vereist is voor de continuïteit van zorg.
2.5.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een update van de paramedicus aan de huisarts
2.5.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Paramedicus | De paramedicus stuurt een update |
Huisarts | De huisarts ontvangt een update |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.5.4 Informatieoverdracht
Zowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- EPD's of ECD's (informatiesystemen voor paramedici).
2.5.4.1 Systemen & Systeemrollen
De huisarts en de paramedicus maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (EPD's of ECD's). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de update aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Update Paramedicus naar Huisarts Sturend Systeem | [HZP-UAS] | Sturen verwijzing van de paramedicus naar de huisarts |
EPD's of ECD's | Huisartsen Zorg Proces – Update paramedicus naar Huisarts Ontvangend Systeem | [HZP-UAO] | Ontvangen verwijzing van de paramedicus door de huisarts |
Zie ook onderstaande afbeelding:
2.5.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen update (PUSH) | Sturen update | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen update |
2.5.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de update van de paramedicus aan de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Paramedicus stuurt update aan huisarts | Sturen update (PUSH) | Sturen update door huisarts aan paramedicus | [HZP-UAS] | EPD of ECD | Paramedicus |
2.6 Use case: Paramedicus stuurt eindrapportage aan arts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.6.1 Doel en Relevantie
De eindrapportage wordt gestuurd bij de afsluiting van de behandeling, onafhankelijk van de reden hiervoor. Het paramedische traject wordt hiermee afgesloten. De eindrapportage bevat inzicht in de gegeven behandeling door de paramedicus en het resultaat daarvan. Met het versturen van de eindrapportage wordt het paramedische traject afgesloten en gaat de verantwoordelijkheid voor de zorg van de patiënt terug naar de huisarts.
2.6.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht stuurt:
- bij afsluiten van de behandeling, onafhankelijk van de reden hiervoor (➞ eindrapportage)
Een reden om hiervan af te wijken is dat de patiënt expliciet bezwaar maakt tegen berichtgeving aan de huisarts en de paramedicus erin kan meegaan om deze berichtgeving achterwege te laten.
2.6.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een eindrapportage van een paramedicus aan de huisarts.
2.6.2.2 Proces
Het proces van deze use case is:
- De eindrapportage wordt zo snel mogelijk verstuurd en uiterlijk binnen 5 werkdagen na het betreffende zorgmoment of nadat een vraag is gesteld.
2.6.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een eindrapportage van een paramedicus aan de huisarts.
2.6.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Paramedicus | De paramedicus stuurt de eindrapportage |
Huisarts | De huisarts ontvangt de eindrapportage |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.6.4 Informatieoverdracht
Zowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- EPD's of ECD's (informatiesystemen voor paramedici).
2.6.4.1 Systemen & Systeemrollen
De huisarts en de paramedicus maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (EPD's of ECD's). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het sturen van de eindrapportage aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
EPD's of ECD's | Huisartsen Zorg Proces – Eindrapportage Paramedicus naar Huisarts Sturend Systeem | [HZP-EPS] | Sturen eindrapportage aan de huisarts |
HIS | Huisartsen Zorg Proces –Eindrapportage Paramedicus naar Huisarts Ontvangend Systeem | [HZP-EPO] | Ontvangen eindrapportage door de huisarts |
Zie ook onderstaande afbeelding:
2.6.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen eindrapportage (PUSH) | Sturen eindrapportage | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen eindrapportage |
2.6.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van het sturen van de eindrapportage aan de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Paramedicus stuurt eindrapportage aan huisarts | Sturen eindrapportage (PUSH) | Sturen eindrapportage door huisarts aan paramedicus | [HZP-EPS] | EPD of ECD | Paramedicus |
2.7 Use case: Paramedicus draagt over aan paramedicus (paramedische overdracht)
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.7.1 Doel en Relevantie
Het overdrachtsbericht bevat inzicht in de gegeven behandeling door de paramedicus en het resultaat daarvan. Dit bericht wordt ook wel de ‘overdracht’ genoemd. Deze use case beschrijft de reden van het versturen van dit bericht. In dit bericht zitten alle gegevens dit de collega paramedicus nodig heeft om de patiënt te kunnen ontvangen en de behandeling te kunnen voortzetten. Bij de paramedische overdracht draagt de paramedicus de verantwoordelijkheid van de zorg voor de patiënt over aan een collega paramedicus.
2.7.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht stuurt:
- bij overdracht van de patiënt naar een collega paramedicus als de verantwoordelijkheid ook over gaat naar die collega (➞ overdracht)
2.7.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor de paramedische overdracht.
2.7.2.2 Proces
Het proces van deze use case is:
- Patiënt komt bij paramedicus via paramedische overdracht
2.7.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor de paramedische overdracht.
2.7.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Paramedicus A | Paramedicus A stuurt overdrachtsbericht aan paramedicus B |
Paramedicus B | Paramedicus B ontvangt overdrachtsbericht van paramedicus A |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.7.4 Informatieoverdracht
Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- EPD's of ECD's (informatiesystemen voor paramedici).
2.7.4.1 Systemen & Systeemrollen
Paramedici maken gebruik van een informatiesysteem: EPD's of ECD's. Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de overdracht aan een collega paramedicus mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
EPD's of ECD's | Huisartsen Zorg Proces – Overdracht Paramedicus naar Paramedicus Sturend Systeem | [HZP-OPS] | Sturen overdrachtsbericht aan collega paramedicus |
EPD's of ECD's | Huisartsen Zorg Proces –Overdracht Paramedicus naar Paramedicus Ontvangend Systeem | [HZP-OPO] | Ontvangen overdrachtsbericht door collega paramedicus |
Zie ook onderstaande afbeelding:
2.7.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen overdrachtsbericht (PUSH) | Sturen overdrachtsbericht | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen overdrachtsbericht |
2.7.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de paramedische overdracht:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Paramedicus draagt over aan paramedicus | Sturen overdrachtsbericht (PUSH) | Sturen overdrachtsbericht door paramedicus aan collega paramedicus | [HZP-OPS] | EPD of ECD | Paramedicus |
2.8 Use case: Huisarts verwijst naar medisch specialist
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.8.1 Doel en Relevantie
Het verwijsbericht volgt op de noodzaak om de zorg van de patiënt over te dragen van de huisarts naar de medisch specialist zodat medisch specialistische zorg kan worden geboden.
Deze use case beschrijft de reden van het versturen van het verwijsbericht. In dit bericht zitten alle benodigde gegevens voor de medisch specialist om de patiënt te kunnen ontvangen en de behandeling te kunnen starten. Met dit verwijsbericht wordt ook de verantwoordelijkheid voor de zorg voor de patiënt deels of volledig wordt overgedragen.
2.8.2 Proces en Context (pre- en postproces)
De NHG richtlijn geeft aan dat de huisarts altijd een verwijsbericht stuurt:
- Op het moment van verwijzen.
2.8.2.1 Preproces
Een huisarts gaat een verwijsbericht sturen naar een medisch specialist.
2.8.2.2 Proces
Het proces van deze use case is:
- De huisarts stuurt een verwijsbericht naar medisch specialist
- Het verwijsbericht is beschikbaar in de tweede lijn op het moment van overname.
2.8.2.3 Postproces
De medisch specialist heeft het verwijsbericht ontvangen van de huisarts.
2.8.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Huisarts | De huisarts stuurt een verwijsbericht |
Medisch specialist | De medisch specialist ontvangt verwijsbericht |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.8.4 Informatieoverdracht
2.8.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ziekenhuisinformatiesysteem (ZIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de verwijzing naar de medisch specialist mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Verwijsbericht Huisarts naar Specialist Sturend Systeem | [HZP-VSS] | Sturen verwijzing van de huisarts naar de medisch specialist |
ZIS | Huisartsen Zorg Proces - Verwijsbericht Huisarts naar Specialist Ontvangend Systeem | [HZP-VSO] | Ontvangen verwijzing van de huisarts naar de medisch specialist |
Zie ook onderstaande afbeelding:
2.8.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen verwijzing (PUSH) | Sturen verwijzing | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen verwijzing |
2.8.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de verwijzing door de huisarts naar de medisch specialist:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Huisarts verwijst naar medisch specialist | Sturen verwijzing (PUSH) | Sturen verwijzing door huisarts aan medisch specialist | [HAO-VSS] | HIS | Huisarts |
2.9 Use case: Huisarts stuurt update aan medisch specialist
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.9.1 Doel en Relevantie
Deze use case beschrijft de reden van het versturen van een update door de huisarts aan de medisch specialist. Een update volgt op de noodzaak om de continuïteit in de zorg te borgen. In dit bericht zitten de benodigde gegevens voor de medisch specialist als het gaat om onverwachte bevindingen of gewijzigd beleid voor de patiënt met impact voor de zorg door de medisch specialist. Een huisarts stuurt altijd een update bij overlijden van de patiënt.
2.9.2 Proces en Context (pre- en postproces)
De NHG richtlijn geeft aan dat de huisarts een update overweegt:
- als zich een wijziging in het beloop voordoet, een nieuwe uitslag bekend is, de huisarts met patiënt een gesprek heeft gehad vanwege gezamenlijke besluitvorming over de behandeling in de tweede lijn;
- wanneer de huisarts een diagnose stelt, van diagnose verandert, en/of een behandeling met belangrijke impact inzet of wijzigt, zoals nieuwe medicatie, medicatie wijzigen of stoppen;
- bij een levensgebeurtenis.
De huisarts stuurt altijd een update:
- bij overlijden van de patiënt.
2.9.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een update aan een medisch specialist.
2.9.2.2 Proces
Het proces van deze use case is:
- De huisarts stuurt een update aan de medisch specialist
- Een tussentijdse update vanuit de eerste lijn wordt zo snel als vereist is voor de continuïteit van zorg gedeeld met de medisch specialist en waar nodig met overige betrokken zorgverleners.
2.9.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een update aan een medisch specialist.
2.9.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Huisarts | De huisarts stuurt een update |
Medisch specialist | De medisch specialist ontvangt een update |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.9.4 Informatieoverdracht
Zowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- ZIS (Ziekenhuisinformatiesysteem).
2.9.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ziekenhuisinformatiesysteem (ZIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de update aan de medisch specialist mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Update Huisarts naar Specialist Sturend Systeem | [HZP-UHS] | Sturen update van de huisarts naar de medisch specialist |
ZIS | Huisartsen Zorg Proces – Update Huisarts naar Specialist Ontvangend Systeem | [HZP-UHO] | Ontvangen update van de huisarts door de medisch specialist |
Zie ook onderstaande afbeelding:
2.9.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen update (PUSH) | Sturen update | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen update |
2.9.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de verwijzing door de huisarts naar de paramedicus:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Huisarts stuurt update aan medisch specialist | Sturen update (PUSH) | Sturen update door huisarts aan medisch specialist | [HZP-UHS] | HIS | Huisarts |
2.10 Use case: Medisch specialist stuurt update aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.10.1 Doel en Relevantie
Belangrijke momenten voor de medisch specialist om de huisarts te informeren zijn bij ontslag uit de kliniek en uit de polikliniek. Maar ook vanuit de tweede lijn is het van belang updates te sturen steeds als er nieuwe relevante informatie beschikbaar is voor de huisarts. Dit is de gedeelde verantwoordelijkheid van zorginstelling en medisch specialist. Ook hier is het helder dat dit van belang is voor de continuïteit van zorg voor de patiënt en mogelijk diens thuisfront.
2.10.2 Proces en Context (pre- en postproces)
De NHG richtlijn (HASP) geeft aan dat de medisch specialist een update overweegt in de volgende gevallen:
Vanuit polikliniek:
- zodra de medisch specialist een werkhypothese en een plan heeft opgesteld;
- bij het stellen van een diagnose en/of inzetten of wijzigen van therapie met belangrijke impact, zoals nieuwe medicatie, gewijzigd therapieschema, uitstel interventie, time-out voor de patiënt voorafgaand aan de keuze voor behandeling starten hetzij voortzetten (bijvoorbeeld bij patiënten met kanker), plaatsen op de opnamelijst;
- na behandeling/ingreep op de dagbehandeling (bijvoorbeeld indien het een invasieve interactie betreft en kans op bijvoorbeeld nabloeden aanwezig is);
- (na het versturen van het ontslagbericht): nagekomen uitslag die relevant is;
- als de patiënt lang onder controle blijft: op gezette tijden rapportage over het ingezette traject.
Vanuit kliniek:
- bij opname (vaak stuurt het ziekenhuis een opnamebericht; indien dit bericht ook de opname-indicatie vermeldt en de huisarts middels een eerdere update al op de hoogte is van de reden van opname, kan een extra update wellicht achterwege blijven; hetzelfde geldt bij opname vanaf de spoedeisende-hulpafdeling: indien de huisarts al op de hoogte is van de opname en de reden hiervoor, kan de extra update vervallen);
- bij het stellen van een diagnose en/of inzetten of wijzigen van therapie met belangrijke impact, zoals nieuwe medicatie, gewijzigd behandelschema, uitstel van de interventie, of bij een time-out voor de patiënt voorafgaand aan de keuze voor behandeling starten hetzij voortzetten;
- bij onverwachte opname op de ic; bij onverwachte bevinding bij een operatie.
De medisch specialist stuurt altijd een update vanuit de kliniek:
- bij overlijden van de patiënt.
2.10.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een update van een medisch specialist aan een huisarts.
2.10.2.2 Proces
Het proces van deze use case is:
- De medisch specialist stuurt update aan de huisarts
- Updates richting de verwijzer vinden plaats zo snel als vereist is voor de continuïteit van zorg.
2.10.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een update van een medisch specialist aan een huisarts.
2.10.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Medisch specialist | De medisch specialist stuurt een update |
Huisarts | De huisarts ontvangt een update |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.10.4 Informatieoverdracht
Zowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- ZIS (Ziekenhuisinformatiesysteem).
2.10.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ziekenhuisinformatiesysteem (ZIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de update aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Update Specialist naar Huisarts Sturend systeem | [HZP-USS] | Sturen update van de medisch specialist aan de huisarts |
ZIS | Huisartsen Zorg Proces – Update specialist naar Huisarts Ontvangend Systeem | [HZP-USO] | Ontvangen update van de medisch specialist door de huisarts |
Zie ook onderstaande afbeelding:
2.10.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen update (PUSH) | Sturen update | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen update |
2.10.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de verwijzing door de huisarts naar de paramedicus:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Medisch specialist stuurt update aan huisarts | Sturen update (PUSH) | Sturen update door medisch specialist aan huisarts | [HZP-USS] | ZIS | Medisch specialist |
2.11 Use case: Medisch specialist stuurt ontslagbericht aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.11.1 Doel en Relevantie
Het ontslagbericht wordt door de medisch specialist vanuit de polikliniek aan de huisarts gestuurd bij ontslag uit poliklinische controle. De medisch specialist stuurt een ontslagbericht vanuit de kliniek bij ontslag of bij overplaatsing (naar een andere afdeling).
Vooral bij ontslagberichten prevaleert tijdigheid van berichtgeving boven volledigheid. De huisarts is zeer gediend met een bericht op de dag van ontslag uit de kliniek om continuïteit van zorg te kunnen leveren. Dan zijn vaak de laatste uitslagen nog niet bekend.
2.11.2 Proces en Context (pre- en postproces)
De NHG richtlijn (HASP) geeft aan dat een ontslagbericht wordt gestuurd in de volgende gevallen:
Vanuit de polikliniek:
- bij ontslag uit poliklinische controle.
Vanuit de kliniek:
- bij ontslag (bij doorverwijzing door de medisch specialist naar een andere instelling komt een kopie daarvan voor de huisarts in de plaats van het ontslagbericht);
- bij overplaatsing, al dan niet definitief, naar een andere afdeling.
2.11.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een arts.
2.11.2.2 Proces
Het proces van deze use case is:
- De medisch specialist stuurt een ontslagbericht aan de huisarts
- Het ontslagbericht vanuit de kliniek volgt in principe direct maar uiterlijk binnen 24 uur.
- Het ontslagbericht vanuit de polikliniek volgt zo snel vereist is voor de continuïteit van zorg, maar uiterlijk binnen 5 dagen.
Bij een goed vormgegeven situatie betekent ‘geen bericht’ dat er geen nieuwe ontwikkelingen zijn.
2.11.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een arts.
2.11.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Medisch specialist | De medisch specialist stuurt ontslagbericht |
Huisarts | De huisarts ontvangt ontslagbericht |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.11.4 Informatieoverdracht
Zowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem).
- ZIS (Ziekenhuisinformatiesysteem).
2.11.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ziekenhuisinformatiesysteem (ZIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het sturen van de eindrapportage aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Ontslagbericht Specialist naar Huisarts Sturend Systeem | [HZP-OSS] | Sturen ontslagbericht naar de huisarts |
ZIS | Huisartsen Zorg Proces – Ontslagbericht Specialist naar Huisarts Ontvangend Systeem | [HZP-OSO] | Ontvangen ontslagbericht door de huisarts |
Zie ook onderstaande afbeelding:
2.11.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen eindrapportage (PUSH) | Sturen eindrapportage | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen eindrapportage |
2.11.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van het sturen van het ontslagbericht door de medisch specialist aan de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Medisch specialist stuurt ontslagbericht aan huisarts | Sturen ontslagbericht(PUSH) | Sturen ontslagbericht door medisch specialist aan huisarts | [HZP-OSS] | ZIS | Medisch specialist |
2.12 Use case: Huisarts verwijst naar GGZ
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.12.1 Doel en Relevantie
De Verwijsbrief is het bericht van de huisarts als deze de patiënt verwijst naar een GGZ-instelling of psychiater.
Deze use case beschrijft de reden van het versturen van het verwijsbericht. In dit bericht zitten alle benodigde gegevens voor de GGZ om de patiënt te kunnen ontvangen en de behandeling te kunnen starten.
2.12.2 Proces en Context (pre- en postproces)
2.12.2.1 Preproces
Een huisarts gaat een verwijsbericht sturen naar de GGZ.
2.12.2.2 Proces
Het proces van deze use case is:
- De huisarts stuurt een verwijsbericht naar de GGZ
- Het verwijsbericht is beschikbaar in de tweede lijn op het moment van overname.
2.12.2.3 Postproces
De GGZ-hulpverlener heeft het verwijsbericht ontvangen van de huisarts.
2.12.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Huisarts | De huisarts stuurt een verwijsbericht |
De GGZ | De GGZ ontvangt een verwijsbericht |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.12.4 Informatieoverdracht
2.12.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en GGZ-informatiesysteem (XIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van de verwijzing naar de medisch specialist mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
HIS | Huisartsen Zorg Proces – Verwijsbericht Huisarts naar GGZ Sturend Systeem | [HZP-VGS] | Sturen verwijzing van de huisarts naar de GGZ |
XIS | Huisartsen Zorg Proces - Verwijsbericht Huisarts naar GGZ Ontvangend Systeem | [HZP-VGO] | Ontvangen verwijzing van de huisarts naar de GGZ |
Zie ook onderstaande afbeelding:
2.12.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen verwijzing (PUSH) | Sturen verwijzing | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen verwijzing |
2.12.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van de verwijzing door de huisarts naar de medisch specialist:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
Huisarts verwijst naar de GGZ | Sturen verwijzing (PUSH) | Sturen verwijzing door huisarts aan de GGZ | [HZP-VGS] | HIS | Huisarts |
2.13 Use case: GGZ raadpleegt professionele samenvatting (ps)
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.13.1 Doel en Relevantie
Bij direct contact tussen patiënt en GGZ zonder tussenkomst van de huisarts, moet de GGZ kunnen beschikken over een ‘professionele samenvatting’ van het dossier van de huisarts. De Professionele samenvatting voor de GGZ stelt de GGZ in staat om gegevens in te zien in het dossier van de huisarts bij diens afwezigheid.
Deze use case beschrijft de reden van het versturen van een professionele samenvatting. In dit bericht zitten alle benodigde gegevens voor de GGZ om de patiënt te kunnen ontvangen.
2.13.2 Proces en Context (pre- en postproces)
2.13.2.1 Preproces
Een GGZ-instelling raadpleegt de professionele samenvatting bij de huisarts.
2.13.2.2 Proces
Het proces van deze use case is:
- De huisarts stelt de professionele samenvatting beschikbaar aan de GGZ
- De professionele samenvatting is beschikbaar voor de GGZ.
2.13.2.3 Postproces
De GGZ-hulpverlener is in staat om gegevens in te zien in het dossier van de huisarts.
2.13.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
De GGZ | De GGZ-hulpverlener raadpleegt de professionele samenvatting |
De huisarts | De huisarts stelt de professionele samenvatting beschikbaar |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.13.4 Informatieoverdracht
2.13.4.1 Systemen & Systeemrollen
De GGZ-instelling en de huisarts maken ieder gebruik van een informatiesysteem, respectievelijk GGZ-informatiesysteem (XIS) en Huisartseninformatiesysteem (HIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van mogelijk maken van het inzien van de professionele samenvating. In ART-DECOR worden de systeemrollen als actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
XIS | Huisartsen Zorg Proces – Professionele samenvatting raadplegend Systeem | [HZP-PRS] | Raadplegen professionele samenvatting door de GGZ-instelling bij de huisarts |
HIS | Huisartsen Zorg Proces - Professionele samenvatting Beschikbaarstellend Systeem | [HZP-PBS] | Beschikbaarstellen professionele samenvatting door de huisarts |
Zie ook onderstaande afbeelding:
2.13.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Raadplegen professionele samenvatting (PULL) | Raadplegen professionele samenvatting | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Beschikbaarstellen professionele samenvatting |
2.13.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van het raadplegen van de professionele samenvatting door de GGZ-hulpverlener bij de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
De GGZ-hulpverlener raadpleegt de professionele samenvatting | Raadplegen professionele samenvatting (PULL) | De huisarts stelt de professionele samenvatting beschikbaar aan de aan de GGZ-hulpverlener | [HZP-PRS] | XIS | GGZ |
2.14 Use case: GGZ stuurt bericht aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.14.1 Doel en Relevantie
2.14.2 Proces en Context (pre- en postproces)
2.14.2.1 Preproces
2.14.2.2 Proces
2.14.2.3 Postproces
2.14.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.14.4 Informatieoverdracht
2.14.4.1 Systemen & Systeemrollen
2.14.4.2 Transacties & Transactiegroepen
2.14.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.15 Use case: GGZ stuurt update aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.15.1 Doel en Relevantie
2.15.2 Proces en Context (pre- en postproces)
2.15.2.1 Preproces
2.15.2.2 Proces
2.15.2.3 Postproces
2.15.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.15.4 Informatieoverdracht
2.15.4.1 Systemen & Systeemrollen
2.15.4.2 Transacties & Transactiegroepen
2.15.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.16 Use case: GGZ stuurt ontslagbericht aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.16.1 Doel en Relevantie
Het ontslagbericht wordt door de GGZ-instelling aan de huisarts gestuurd na afsluiting van de behandeling. De aanleiding kan zijn dat de behandeling is afgerond, maar ook dat de cliënt bijvoorbeeld verhuist naar een instelling voor ouderenzorg.
2.16.2 Proces en Context (pre- en postproces)
De NHG richtlijn HASP-GGZ geeft aan dat een ontslagbericht wordt gestuurd na afsluiting van de behandeling door de GGZ-instelling
2.16.2.1 Preproces
Er zijn geen precondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een huisarts.
2.16.2.2 Proces
Het proces van deze use case is:
- De GGZ-hulpverlener stuurt een ontslagbericht aan de huisarts
2.16.2.3 Postproces
Er zijn geen postcondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een huisarts.
2.16.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
De GGZ | De GGZ-hulpverlener stuurt ontslagbericht |
Huisarts | De huisarts ontvangt ontslagbericht |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.16.4 Informatieoverdracht
Zowel GGZ-instellingen als huisartsen maken gebruik van een informatiesysteem, respectievelijk:
- GGZ-informatiesysteem (XIS);
- HIS (Huisartsinformatiesysteem).
2.16.4.1 Systemen & Systeemrollen
De huisarts en de medisch specialist maken ieder gebruik van een informatiesysteem, respectievelijk GGZ-informatiesysteem (XIS) en Huisartseninformatiesysteem (HIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het sturen van de ontslagbericht aan de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
XIS | Huisartsen Zorg Proces – Ontslagbericht GGZ naar Huisarts Sturend Systeem | [HZP-OGS] | Sturen ontslagbericht naar de huisarts |
HIS | Huisartsen Zorg Proces – Ontslagbericht GGZ naar Huisarts Ontvangend Systeem | [HZP-OGO] | Ontvangen ontslagbericht door de huisarts |
Zie ook onderstaande afbeelding:
2.16.4.2 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Link naar transactie | Link naar FHIR-profiel |
---|---|---|---|
Sturen ontslagbericht(PUSH) | Sturen ontslagbericht | Volgt zodra beschikbaar | Volgt zodra beschikbaar |
Ontvangen ontslagbericht |
2.16.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel uitmaken van het sturen van de ontslagbericht door de GGZ-instelling aan de huisarts:
Use case | Transactiegroep | Transactie | Systeemgroep | Systeem | Bedrijfsrol |
---|---|---|---|---|---|
GGZ-hulpverlener stuurt ontslagbericht aan huisarts | Sturen ontslagbericht(PUSH) | Sturen ontslagbericht door GGZ-hulpverlener aan huisarts | [HZP-OGS] | XIS | GGZ |
2.17 Use case: Huisarts verwijst naar ketenzorgpartner
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.17.1 Doel en Relevantie
2.17.2 Proces en Context (pre- en postproces)
2.17.2.1 Preproces
2.17.2.2 Proces
2.17.2.3 Postproces
2.17.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.17.4 Informatieoverdracht
2.17.4.1 Systemen & Systeemrollen
2.17.4.2 Transacties & Transactiegroepen
2.17.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.18 Use case: Ketenzorgpartner raadpleeg dossier bij huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.18.1 Doel en Relevantie
2.18.2 Proces en Context (pre- en postproces)
2.18.2.1 Preproces
2.18.2.2 Proces
2.18.2.3 Postproces
2.18.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.18.4 Informatieoverdracht
2.18.4.1 Systemen & Systeemrollen
2.18.4.2 Transacties & Transactiegroepen
2.18.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.19 Use case: Ketenzorgpartner stuurt eindrapportage aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.19.1 Doel en Relevantie
2.19.2 Proces en Context (pre- en postproces)
2.19.2.1 Preproces
2.19.2.2 Proces
2.19.2.3 Postproces
2.19.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.19.4 Informatieoverdracht
2.19.4.1 Systemen & Systeemrollen
2.19.4.2 Transacties & Transactiegroepen
2.19.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.20 Use case: Patiënt raadpleegt dossier huisartsgegevens
Note: zie MedMij
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.20.1 Doel en Relevantie
2.20.2 Proces en Context (pre- en postproces)
2.20.2.1 Preproces
2.20.2.2 Proces
2.20.2.3 Postproces
2.20.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.20.4 Informatieoverdracht
2.20.4.1 Systemen & Systeemrollen
2.20.4.2 Transacties & Transactiegroepen
2.20.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.21 Use case: Huisarts stuurt vragenlijst aan patiënt
Note: Huisarts zet vragenlijst klaar voor patiënt
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.21.1 Doel en Relevantie
2.21.2 Proces en Context (pre- en postproces)
2.21.2.1 Preproces
2.21.2.2 Proces
2.21.2.3 Postproces
2.21.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.21.4 Informatieoverdracht
2.21.4.1 Systemen & Systeemrollen
2.21.4.2 Transacties & Transactiegroepen
2.21.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.22 Use case: Patiënt stuurt antwoorden op vragenlijst aan huisarts
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.22.1 Doel en Relevantie
2.22.2 Proces en Context (pre- en postproces)
2.22.2.1 Preproces
2.22.2.2 Proces
2.22.2.3 Postproces
2.22.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.22.4 Informatieoverdracht
2.22.4.1 Systemen & Systeemrollen
2.22.4.2 Transacties & Transactiegroepen
2.22.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.23 Use case: Patiënt stuurt zelfmeting aan huisarts
Note: Nog geen richtlijn beschikbaar
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.23.1 Doel en Relevantie
2.23.2 Proces en Context (pre- en postproces)
2.23.2.1 Preproces
2.23.2.2 Proces
2.23.2.3 Postproces
2.23.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |
2.23.4 Informatieoverdracht
2.23.4.1 Systemen & Systeemrollen
2.23.4.2 Transacties & Transactiegroepen
2.23.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen
2.24 Use case: Patiënt raadpleegt afspraak bij huisarts
Note: de tijd van de afspraak
De Use case is nog in ontwikkeling en nog niet geschikt voor gebruik! |
2.24.1 Doel en Relevantie
2.24.2 Proces en Context (pre- en postproces)
2.24.2.1 Preproces
2.24.2.2 Proces
2.24.2.3 Postproces
2.24.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
A | B |
C | D |