hg:Vprepub-1 Ontwerp ELZ: verschil tussen versies
(ELZT-65: Wijzigen "actuele dossiergegevens" naar "gegevens op moment van verwijzen") |
(Verwijzing naar ART-DECOR-transactie bijgewerkt) |
||
Regel 275: | Regel 275: | ||
|style="background-color: white;vertical-align:middle;"|HIS | |style="background-color: white;vertical-align:middle;"|HIS | ||
|style="background-color: white;vertical-align:middle;"|HZP-VPS | |style="background-color: white;vertical-align:middle;"|HZP-VPS | ||
− | |style="background-color: white;vertical-align:middle;" rowspan="2"|[https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html- | + | |style="background-color: white;vertical-align:middle;" rowspan="2"|[https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html-20230612T223800/tr-2.16.840.1.113883.2.4.3.11.60.103.4.17-2021-12-13T165549.html Publicatie in ART-DECOR] |
|- | |- | ||
|style="background-color: white;vertical-align:top;"|Ontvangen verwijzing | |style="background-color: white;vertical-align:top;"|Ontvangen verwijzing | ||
Regel 297: | Regel 297: | ||
|} | |} | ||
− | De informatie-elementen en het scenario voor deze usecase staan in ART-DECOR. Deze informatie is [https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html- | + | De informatie-elementen en het scenario voor deze usecase staan in ART-DECOR. Deze informatie is [https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html-20230612T223800/tr-2.16.840.1.113883.2.4.3.11.60.103.4.17-2021-12-13T165549.html hier] te openen en wordt hieronder gepresenteerd. |
<html> | <html> | ||
− | <iframe width="100%" height="800" src=https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html- | + | <iframe width="100%" height="800" src=https://decor.nictiz.nl/pub/eerstelijnszorg/hg-html-20230612T223800/tr-2.16.840.1.113883.2.4.3.11.60.103.4.17-2021-12-13T165549.html frameborder="0" align="middle"></iframe> |
</html> | </html> | ||
Huidige versie van 11 jul 2023 om 07:42
|
Dit functioneel ontwerp is momenteel in ontwikkeling en kan niet als stabiel worden beschouwd. Voor vragen en wijzigingsverzoeken over deze pagina kan een ticket worden aangemaakt in BITS. |
Inhoud
- 1 Inleiding
- 2 Usecases
- 3 Concept-usecases
- 3.1 Usecase: Huisarts stuurt dossier naar huisarts
- 3.2 Usecase: Waarnemend huisarts raadpleegt professionele samenvatting (ps)
- 3.3 Usecase: Waarnemend huisarts stuurt waarneemretourbericht (wrb)
- 3.4 Usecase: Paramedicus stuurt bericht directe toegang (DT) naar huisarts
- 3.5 Usecase: Huisarts stuurt update naar paramedicus
- 3.6 Usecase: Paramedicus stuurt update naar huisarts
- 3.7 Usecase: Paramedicus stuurt eindrapportage naar huisarts
- 3.8 Usecase: Paramedicus draagt over aan paramedicus (paramedische overdracht)
- 3.9 Usecase: Huisarts verwijst naar medisch specialist
- 3.10 Usecase: Huisarts stuurt update naar medisch specialist
- 3.11 Usecase: Medisch specialist stuurt update naar huisarts
- 3.12 Usecase: Medisch specialist stuurt ontslagbericht naar huisarts
- 3.13 Usecase: Huisarts verwijst naar GGZ
- 3.14 Usecase: GGZ raadpleegt professionele samenvatting (ps)
- 3.15 Usecase: Wederzijds bericht Wijziging somatiek/therapie/controles huisarts <-> GGZ
- 3.16 Usecase: GGZ stuurt bericht kennisgeving patiënt heeft afspraak
- 3.17 Usecase: GGZ stuurt bericht na intake naar huisarts
- 3.18 Usecase: GGZ stuurt bericht Kennisgeving overdracht behandeling naar GGZ
- 3.19 Usecase: GGZ stuurt bericht voortgang naar de huisarts
- 3.20 Usecase: GGZ stuurt bericht einde behandeling naar huisarts
- 3.21 Usecase: Huisarts verwijst naar ketenzorgpartner
- 3.22 Usecase: Ketenzorgpartner stuurt eindrapportage naar huisarts
- 3.23 Usecase: Patiënt raadpleegt dossier huisartsgegevens
- 3.24 Usecase: Huisarts stuurt vragenlijst aan patiënt
- 3.25 Usecase: Patiënt stuurt antwoorden op vragenlijst aan huisarts
- 3.26 Usecase: Patiënt stuurt zelfmeting aan huisarts
- 3.27 Usecase: Patiënt raadpleegt afspraak bij huisarts
- 4 Release notes
1 Inleiding
1.1 Algemeen
Deze pagina beschrijft het functioneel ontwerp voor ELZ (Eerstelijnszorg). Dit ontwerp wordt gebruikt door de informatiestandaarden Huisartsenzorg en Paramedische Zorg. Ook bevat het functionele usecases voor Ketenzorg, Huisartswaarneming, GGZ en raadpleging van het huisartsendossier door de patiënt. Het functioneel ontwerp beschrijft voor alle uitwisselscenario's (in dit document usecases genoemd) uit de informatiestandaard de transacties, transactiegroepen, de systemen, de systeemrollen en de bedrijfsrollen van zorgverleners of patiënten. Daarvoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 wordt verder ingegaan op wat een usecase inhoudt. Per usecase 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. De technische tegenhanger van dit functioneel ontwerp is te vinden op het technisch ontwerp (FHIR IG).
Het proces voor gegevensuitwisseling met de huisarts is in onderstaande afbeelding gevisualiseerd:
Figuur: Proces uitwisseling huisartsgegevens
1.2 Doelgroep
De doelgroepen van dit functionele ontwerp zijn:
- Productmanagers, architecten, ontwerpers en testers van XIS-leveranciers, zorgorganisaties en Nictiz;
- Zorgverleners en hun vertegenwoordigers;
- Patiënten
1.3 Kaders & Uitgangspunten
Eerstelijnszorg maakt waar mogelijk gebruik van zorginformatiebouwstenen (zibs), publicatie 2020, de uitwisselstandaard is HL7 FHIR R4.
|
De FHIR-profielen gedefinieerd voor zib-publicatie 2020 zijn momenteel in betastatus. Ondanks dat grote wijzigingen niet worden verwacht, dienen gebruikers zich ervan bewust te zijn dat er incompatibele wijzigingen doorgevoerd kunnen worden voordat een stabiele versie is bereikt. Daarom kunnen deze profielen niet beschouwd worden als geschikt voor gegevensuitwisseling in de praktijk. |
1.3.1 Richtlijn en proces
1.3.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.3.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.3.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.3.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.3.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.3.1.6 Ketenzorg
De ketenzorgoverdracht is gebaseerd op de volgende zorgstandaarden:
- NDF Zorgstandaard Diabetes;
- Zorgstandaard COPD;
- Nederlandse Multidisciplinaire richtlijn Cardiovasculair risicomanagement (MDR CVRM) en de daarvan afgeleide NHG-Standaard;
- Ouderenzorg
Er zijn afspraken tussen de ketenpartijen over de gegevens waartoe de zorgverleners toegang hebben. Dit betekent dat een zorgverlener, zoals een POH, alleen de gegevens ziet die relevant zijn voor de behandeling van patiënt. Een voorbeeld van een praktische uitwerking hiervan is de AutorisatieMatrix die binnen de zorgtoepassing LSP Ketenzorg van VZVZ wordt toegepast.
1.3.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.3.2 Reikwijdte ontwerp
De reikwijdte van dit ontwerp beslaat de functionele beschrijvingen en de dataset voor alle gegevensuitwisselingen binnen één of meerdere zorgprocessen.
1.3.3 Infrastructuur
De specificatie van de infrastructuur waarover berichten worden uitgewisseld valt buiten de scope van dit ontwerp.
1.4 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 Usecases
|
Op dit moment ondersteunt dit ontwerp alleen de #Usecase:_Huisarts_verwijst_naar_paramedicus met uitzondering van relevante dossiergegevens. De andere usecases zijn nog in ontwikkeling. Deze concept-usecases zijn al wel (ingeklapt) opgenomen onderaan deze pagina en kunnen indien gewenst worden bekeken. |
Een usecase 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 usecase is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere usecases. Iedere usecase koppelt met een scenario in ART-DECOR. Wanneer verschillende usecases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces. In dit functioneel ontwerp wordt elke usecase geanalyseerd en uitgewerkt.
2.1 Algemeen
De informatiestandaard Huisartsenzorg is ingedeeld in verschillende (ontwerp) groepen.
- Dossierverhuisbericht
- Huisartswaarneming
- Verwijzing Paramedicus
- Verwijzing Specialist
- Verwijzing GGZ
- Ketenzorg
- Patiënten overdrachten
- Labuitwisseling (usecases opgenomen in aparte informatiestandaard)
- Acute Zorg (usecases opgenomen in aparte informatiestandaard)
- Medicatieveiligheid (usecases opgenomen in aparte informatiestandaard)
2.1.1 Dossierverhuisbericht
De groep ‘Dossierverhuisbericht’ kent 1 usecase:
2.1.2 Huisartswaarneming
De groep ‘Huisartswaarneming’ kent 2 usecases:
- Waarnemend huisarts raadpleegt professionele samenvatting (ps)
- Waarnemend huisarts stuurt waarneembericht
2.1.3 Verwijzing huisarts naar paramedicus
Informatie-uitwisseling tussen arts en paramedicus vindt plaats op het moment dat de arts respectievelijk de paramedicus moet stilstaan bij de informatiebehoefte over en weer. Bij verwijzing, directe toegang en afronding behandeling zijn de momenten van uitwisseling: het moment van verwijzen of starten respectievelijk het moment van afronding en op momenten van tussentijdse updates.
De volgende beroepen worden benoemd in de NHG-richtlijn HASP-paramedicus:
- Diëtetiek
- Ergotherapie
- Huidtherapie
- Fysiotherapie
- Logopedie en Foniatrie
- Oefentherapie Cesar en Mensendieck
De groep ‘Verwijzing Huisarts naar Paramedicus’ kent 6 usecases:
- Huisarts verwijst naar paramedicus
- Paramedicus stuurt bericht directe toegang naar huisarts
- Huisarts stuurt update naar paramedicus
- Paramedicus stuurt update naar huisarts
- Paramedicus stuurt eindrapportage naar huisarts
- Paramedicus draagt over aan paramedicus
Een samenvatting van de usecases wordt getoond in onderstaand figuur. FIGUUR HASP-PARAMEDICUS INVOEGEN
2.1.4 Verwijzing huisarts naar medisch specialist
Informatie-uitwisseling tussen arts en medisch specialist vindt plaats op het moment dat de huisarts (verwijzer) respectievelijk de medisch specialist (geconsulteerde) moet stilstaan bij de informatiebehoefte over en weer. Bij verwijzing of ontslag zijn de momenten van uitwisseling: het moment van verwijzen respectievelijk het ontslag en op momenten van tussentijdse updates.
De groep ‘Verwijzing Specialist’ kent 4 usecases:
- Huisarts verwijst naar medisch specialist
- Huisarts stuurt update naar medisch specialist
- Medisch specialist stuurt update naar huisarts
- Medisch specialist stuurt ontslagbericht naar huisarts
Een samenvatting van de usecases wordt getoond in onderstaand figuur. FIGUUR HASP-SPECIALIST INVOEGEN
2.1.5 Verwijzing huisarts naar GGZ
De groep ‘Verwijzing huisarts naar GGZ’ kent x usecases:
- Huisarts verwijst naar GGZ
- GGZ raadpleegt professionele samenvatting (ps)
- GGZ stuurt bericht naar huisarts
- GGZ stuurt update naar huisarts
- GGZ stuurt ontslagbericht naar huisarts
Een samenvatting van de usecases wordt getoond in onderstaand figuur. FIGUUR HASP-GGZ INVOEGEN
2.1.6 Ketenzorg
De groep ‘Ketenzorg’ kent 2 usecases:
2.1.7 Patiënten overdrachten
De groep ‘Patiënten overdrachten’ kent 5 usecases:
- Patiënt raadpleegt dossier huisartsengegevens
- Huisarts stuurt vragenlijst naar patiënt
- Patiënt stuurt antwoorden op vragenlijst naar huisarts
- Patiënt stuurt zelfmeting naar huisarts
- Patiënt raadpleegt afspraak bij huisarts (tijd van de afspraak)
2.2 Usecase: Huisarts verwijst naar paramedicus
|
Deze usecase is in ontwikkeling en nog niet geschikt voor gebruik. |
2.2.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 paramedicus zodat paramedische zorg kan worden geboden. Deze usecase beschrijft de reden van het versturen van het verwijsbericht. In dit verwijsbericht zitten de gegevens van de envelop, kern en dossiergegevens zoals gespecificeerd in de HASP-Paramedicus richtlijn.
Voor een verwijzing geldt dat de huisarts en de paramedicus de regel volgen dat de paramedicus de verantwoordelijkheid neemt voor de paramedische diagnostiek en de paramedische behandeling van de klacht of zorgvraag. Met het versturen van het verwijsbericht wordt ook de verantwoordelijkheid voor de zorg voor de patiënt overgedragen.
2.2.2 Proces en Context (pre- en postproces)
De NHG-richtlijn HASP-Paramedicus geeft aan dat de huisarts altijd een verwijsbericht stuurt:
- Op het moment van verwijzen;
- Bij een eenmalig consult (consultatieaanvraag).
2.2.2.1 Preproces
- De huisarts gaat een verwijsbericht sturen naar een paramedicus of paramedische zorgaanbieder;
- De huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO).
2.2.2.2 Proces
Het proces van deze usecase is:
- De huisarts stuurt vanuit het HIS het verwijsbericht (Envelop, Kern en Dossiergegevens) naar een paramedicus;
- Het informatiesysteem van de paramedicus (PARIS) ontvangt en verwerkt deze gegevens.
2.2.2.3 Postproces
De paramedicus heeft het verwijsbericht ontvangen van de huisarts en gebruikt deze gegevens voor de behandeling van de patiënt.
2.2.3 Bedrijfsrollen en UML activity diagram
Bedrijfsrol (actor) | Beschrijving bedrijfsrol |
---|---|
Huisarts | De huisarts stuurt verwijsbericht |
Paramedicus | De paramedicus ontvangt verwijsbericht |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren:
2.2.4 Informatieoverdracht
Zowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
- HIS (Huisartsinformatiesysteem);
- PARIS (Paramedisch informatiesysteem).
2.2.4.1 Systemen & Systeemrollen
Het HIS en het PARIS kennen ieder verschillende systeemrollen die het uitwisselen van gegevens tussen deze systemen in het kader van een verwijzing naar een paramedicus 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 |
PARIS | 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.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt.
Elke usecase bestaat uit de volgende verbanden:
- Een usecase bevat een transactiegroep.
- Een transactiegroep bestaat uit transacties.
- Een transactie wordt uitgevoerd door een bedrijfsrol.
- Bedrijfsrollen maken gebruik van systemen.
- Een systeemrolcode geeft de transactiegroep en de transactie aan waar het systeem voor gebruikt wordt.
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
Usecase | Transactiegroep | Transactie | Bedrijfsrol | Systeem | Systeemrolcode | Publicatie |
---|---|---|---|---|---|---|
Huisarts verwijst naar paramedicus | Sturen verwijzing (PUSH) | Sturen verwijzing | Huisarts | HIS | HZP-VPS | Publicatie in ART-DECOR |
Ontvangen verwijzing | Paramedicus | PARIS | HZP-VPO | |||
Raadplegen dossiergegevens (PULL) | Raadplegen dossiergegevens | Paramedicus | PARIS | HZP-AGR | Link naar publicatie volgt zodra beschikbaar | |
Beschikbaarstellen dossiergegevens | Huisarts | HIS | HZP-AGB | |||
Tabel Usecase - Huisarts verwijst naar paramedicus |
De informatie-elementen en het scenario voor deze usecase staan in ART-DECOR. Deze informatie is hier te openen en wordt hieronder gepresenteerd.
3 Concept-usecases
Onderstaande usecases zijn in ontwikkeling en nog niet geldig voor dit ontwerp.
Klik op "tonen" om deze sectie uit te klappen. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
3.1 Usecase: Huisarts stuurt dossier naar huisarts
3.1.1 Doel en RelevantieHet dossieroverdrachtsbericht bevat de medische gegevens welke in aanmerking komen voor overdracht van een huisarts waar een patiënt is (was) ingeschreven naar een huisarts waar de patiënt is (zal worden) ingeschreven. De huisarts levert integrale, persoonlijke en continue zorg aan de patiënt en de huisarts is het eerste medische aanspreekpunt voor de patiënt in de zorg (poortwachter). Men name de aspecten integrale zorg en continuïteit hebben gevolgen voor de inhoud van het medisch dossier bij de huisarts. Het medisch dossier bij de huisarts geeft een overzicht van de medische geschiedenis van een patiënt in de tijd, niet alleen van contacten tussen huisarts en patiënt maar ook van de medische wederwaardigheden met andere zorgverleners zoals andere eerstelijns zorgverleners en medisch specialisten. Het is vanuit deze optiek dus van het grootste belang dat de medische gegevens zoals die worden beheerd door de huisarts optimaal worden overgedragen wanneer de behandelrelatie overgaat van de ene naar de andere huisarts (mutatie). Het overdrachtsbericht volgt op de noodzaak om de dossiervoering van de patiënt over te dragen van de oorspronkelijke huisarts naar de nieuwe huisarts. Hierdoor wordt de continuering van dossiervoering gewaarborgd. Hiervoor is in de richtlijn aangegeven dat de oorspronkelijke huisarts de verzendende partij (verzender) is en de nieuwe huisarts de ontvangende partij (ontvanger). Deze usecase beschrijft de reden van het versturen van het dossieroverdrachtsbericht. In dit bericht zitten alle benodigde gegevens voor de nieuwe huisarts om de patiënt te kunnen ontvangen. Bij de overdracht wordt het gehele actuele medische dossier overgedragen aan de nieuwe huisarts. 3.1.2 Proces en Context (pre- en postproces)3.1.2.1 Preproces
3.1.2.2 ProcesBij overdracht van de behandelrelatie wordt het dossier elektronisch en gestructureerd overdragen conform de informatiestandaard vanuit het HIS van de oorspronkelijke huisarts naar het HIS van de nieuwe huisarts. 3.1.2.3 PostprocesHet ontvangen dossier wordt binnen het HIS geplaatst zodat het door de nieuwe huisarts te gebruiken is voor continuering van dossiervoering voor de patiënt. 3.1.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.1.4 InformatieoverdrachtHuisartsen maken gebruik van een informatiesysteem:
3.1.4.1 Systemen & SysteemrollenHuisartsen maken gebruik van een informatiesysteem, Huisartseninformatiesysteem (HIS). Deze systemen maken het uitwisselen van gegevens in het kader van het sturen van een dossieroverdrachtsbericht aan de nieuwe huisarts mogelijk. In ART-DECOR worden de systeemrollen als actor beschreven.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.1.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.2 Usecase: Waarnemend huisarts raadpleegt professionele samenvatting (ps)
3.2.1 Doel en Relevantie3.2.2 Proces en Context (pre- en postproces)3.2.2.1 Preproces3.2.2.2 Proces3.2.2.3 Postproces3.2.3 Bedrijfsrollen en UML activity diagram
3.2.4 Informatieoverdracht3.2.4.1 Systemen & Systeemrollen3.2.4.2 Transacties & Transactiegroepen3.2.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.3 Usecase: Waarnemend huisarts stuurt waarneemretourbericht (wrb)
3.3.1 Doel en RelevantieDe standaard Huisartswaarneming automatiseert twee vormen van gegevensuitwisseling:
Deze uitwisselingen kunnen plaatsvinden wanneer een patiënt een huisarts bezoekt die niet de zijne is of als een patiënt een huisartsenpost bezoekt.
3.3.2 Proces en Context (pre- en postproces)3.3.2.1 Preproces3.3.2.2 Proces3.3.2.3 Postproces3.3.3 Bedrijfsrollen en UML activity diagram
3.3.4 Informatieoverdracht3.3.4.1 Systemen & Systeemrollen3.3.4.2 Transacties & Transactiegroepen3.3.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.4 Usecase: Paramedicus stuurt bericht directe toegang (DT) naar huisarts
3.4.1 Doel en RelevantieDe paramedicus stuurt altijd een bericht directe toegang:
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. 3.4.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht directe toegang stuurt:
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. 3.4.2.1 PreprocesEen paramedicus gaat een bericht directe toegang sturen sturen naar een huisarts. De huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.4.2.2 ProcesHet proces van deze usecase is:
3.4.2.3 PostprocesDe huisarts heeft het bericht directe toegang ontvangen van de paramedicus en gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.4.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.4.4 InformatieoverdrachtZowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
3.4.4.1 Systemen & SysteemrollenDe paramedicus en de huisarts maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en informatiesystemen voor paramedici (PARIS). 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.
Zie ook onderstaande afbeelding: 3.4.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.5 Usecase: Huisarts stuurt update naar paramedicus
3.5.1 Doel en RelevantieDeze usecase 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. 3.5.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP-paramedicus geeft aan dat de arts altijd een update stuurt:
De arts overweegt een update:
3.5.2.1 PreprocesDe huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.5.2.2 ProcesHet proces van deze usecase is:
3.5.2.3 PostprocesDe paramedicus gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.5.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.5.4 InformatieoverdrachtZowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
3.5.4.1 Systemen & SysteemrollenHet HIS en het PARIS kennen ieder verschillende systeemrollen die het uitwisselen van gegevens tussen deze systemen in het kader van de update naar de paramedicus mogelijk maken. In ART-DECOR worden de systeemrollen als actor beschreven.
Zie ook onderstaande afbeelding: 3.5.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.6 Usecase: Paramedicus stuurt update naar huisarts
3.6.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een update door de paramedicus naar de huisarts. 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. 3.6.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een update stuurt:
De paramedicus overweegt een update:
3.6.2.1 PreprocesDe paramedicus mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.6.2.2 ProcesHet proces van deze usecase is:
3.6.2.3 PostprocesDe huisarts gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.6.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.6.4 InformatieoverdrachtZowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
3.6.4.1 Systemen & SysteemrollenHet HIS en het PARIS (HIS) 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.
Zie ook onderstaande afbeelding: 3.6.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.7 Usecase: Paramedicus stuurt eindrapportage naar huisarts
3.7.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een eindrapportage door de paramedicus naar de huisarts. 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. 3.7.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht stuurt:
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. 3.7.2.1 PreprocesDe paramedicus mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.7.2.2 ProcesHet proces van deze usecase is:
3.7.2.3 PostprocesDe huisarts verwerkt de gegevens uit de eindrapportage in het dossier van de patiënt. 3.7.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.7.4 InformatieoverdrachtZowel Huisartsen als Paramedici maken gebruik van een informatiesysteem, respectievelijk:
3.7.4.1 Systemen & SysteemrollenHet HIS en het PARIS 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.
Zie ook onderstaande afbeelding: 3.7.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.8 Usecase: Paramedicus draagt over aan paramedicus (paramedische overdracht)
3.8.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een overdrachtsbericht door de paramedicus naar de paramedicus. Het overdrachtsbericht bevat inzicht in de gegeven behandeling door de paramedicus en het resultaat daarvan. Dit bericht wordt ook wel de ‘overdracht’ genoemd. 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. 3.8.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP-paramedicus geeft aan dat de paramedicus altijd een bericht stuurt:
3.8.2.1 PreprocesDe paramedicus mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.8.2.2 ProcesHet proces van deze usecase is:
3.8.2.3 PostprocesDe collega paramedicus gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.8.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.8.4 InformatieoverdrachtParamedici maken gebruik van een informatiesysteem:
3.8.4.1 Systemen & SysteemrollenDe PARIS kennen 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.
Zie ook onderstaande afbeelding: 3.8.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.9 Usecase: Huisarts verwijst naar medisch specialist
3.9.1 Doel en RelevantieHet 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 usecase beschrijft de reden van het versturen van het verwijsbericht. In dit verwijsbericht zitten de gegevens van de envelop en de kern zoals gespecificeerd in de HASP-richtlijn. Dit bericht dient ook als een aanwijzing voor de medisch specialist om de benodigde dossiergegevens te kunnen ophalen uit het HIS. Op deze manier kunnen door de medisch specialist de dossiergegevens worden opgehaald op het moment dat de verwijzing wordt opgepakt. Hiermee zijn de meest actuele gegevens voor de medisch specialist beschikbaar. Het apart ophalen van de dossiergegevens valt functioneel nog steeds onder de verwijzing. Voor een verwijzing geldt dat de arts en de medisch specialist de regel volgen dat de medisch specialist de verantwoordelijkheid neemt voor de medisch specialistische diagnostiek en de medisch specialistische behandeling van de klacht of zorgvraag. Met het versturen van het verwijsbericht wordt ook de verantwoordelijkheid voor de zorg voor de patiënt overgedragen. Indien de huisarts de verwijzing wil annuleren, stuurt de huisarts hetzelfde verwijsbericht, met de status geannuleerd. 3.9.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP geeft aan dat de huisarts altijd een verwijsbericht stuurt:
3.9.2.1 Preproces
3.9.2.2 ProcesHet proces van deze usecase is:
3.9.2.3 PostprocesDe medisch specialist heeft het verwijsbericht en de dossiergegevens ontvangen van de huisarts en gebruikt deze gegevens voor de behandeling van de patiënt. 3.9.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.9.4 InformatieoverdrachtZowel huisartsen als medisch specialisten maken gebruik van een informatiesysteem, respectievelijk:
3.9.4.1 Systemen & SysteemrollenHet HIS en het ZIS 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.
Zie ook onderstaande afbeelding: 3.9.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.10 Usecase: Huisarts stuurt update naar medisch specialist
3.10.1 Doel en RelevantieDeze usecase 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. 3.10.2 Proces en Context (pre- en postproces)De NHG-richtlijn HASP geeft aan dat de huisarts een update overweegt:
De huisarts stuurt altijd een update:
3.10.2.1 PreprocesDe huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.10.2.2 ProcesHet proces van deze usecase is:
3.10.2.3 PostprocesDe medisch specialist gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.10.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.10.4 InformatieoverdrachtZowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
3.10.4.1 Systemen & SysteemrollenHet HIS en het ZIS kennen ieder verschillende systeemrollen die het uitwisselen van gegevens tussen deze systemen in het kader van de update naar de medisch specialist mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Zie ook onderstaande afbeelding: 3.10.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.11 Usecase: Medisch specialist stuurt update naar huisarts
3.11.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een update door de medisch specialist naar de huisarts. 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. 3.11.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:
Vanuit kliniek:
De medisch specialist stuurt altijd een update vanuit de kliniek:
3.11.2.1 PreprocesDe medisch specialist mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.11.2.2 ProcesHet proces van deze usecase is:
3.11.2.3 PostprocesDe huisarts gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.11.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.11.4 InformatieoverdrachtZowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
3.11.4.1 Systemen & SysteemrollenDe 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 naar de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Zie ook onderstaande afbeelding: 3.11.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.12 Usecase: Medisch specialist stuurt ontslagbericht naar huisarts
3.12.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een ontslagbericht door de medisch specialist naar de huisarts. 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. 3.12.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:
Vanuit de kliniek:
3.12.2.1 PreprocesDe medisch specialist mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.12.2.2 ProcesHet proces van deze usecase is:
Bij een goed vormgegeven situatie betekent ‘geen bericht’ dat er geen nieuwe ontwikkelingen zijn. 3.12.2.3 PostprocesDe huisarts verwerkt de ontslaggegevens in het dossier van de patiënt. 3.12.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: 3.12.4 InformatieoverdrachtZowel Huisartsen als Medisch Specialisten maken gebruik van een informatiesysteem, respectievelijk:
3.12.4.1 Systemen & SysteemrollenHet HIS en het ZIS kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het sturen van de ontslagbericht naar de huisarts mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Zie ook onderstaande afbeelding: 3.12.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven:
3.13 Usecase: Huisarts verwijst naar GGZ
3.13.1 Doel en RelevantieHet verwijsbericht is het bericht van de huisarts als deze de patiënt verwijst naar een GGZ-instelling of psychiater. Deze usecase 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. TERMINOLOGIE: VERWIJSBRIEF (richtlijn) OF VERWIJSBERICHT (gebruikt in HASP en HASP-P)? 3.13.2 Proces en Context (pre- en postproces)3.13.2.1 PreprocesEen huisarts gaat een verwijsbericht sturen naar de GGZ. De huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). KLOPT DIT OOK BIJ EEN VERWIJZING NAAR DE GGZ STAAT NIET EXPLICIET IN DE RICHTLIJN? 3.13.2.2 ProcesHet proces van deze usecase is:
3.13.2.3 PostprocesDe GGZ-hulpverlener heeft het verwijsbericht ontvangen van de huisarts en gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.13.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.13.4 InformatieoverdrachtZowel Huisartsen als GGZ-hulpverleners maken gebruik van een informatiesysteem, respectievelijk:
3.13.4.1 Systemen & SysteemrollenDe huisarts en de GGZ 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.13.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.14 Usecase: GGZ raadpleegt professionele samenvatting (ps)
3.14.1 Doel en RelevantieBij direct contact tussen patiënt en GGZ zonder tussenkomst van de huisarts, moet de GGZ kunnen beschikken over een professionele samenvatting (ps) 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 usecase 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 en de behandeling te kunnen starten. Het bericht sluit aan bij de berichtgeving zoals met Nictiz is afgesproken voor inzage door de spoedeisende hulp. Het aldaar gestelde is richtinggevend voor de GGZ. TERMINOLOGIE: GGZ OF GGZ-HULPVERLENER? 3.14.2 Proces en Context (pre- en postproces)3.14.2.1 PreprocesEen GGZ-instelling raadpleegt de professionele samenvatting bij de huisarts. De huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). KLOPT DIT OOK BIJ HET OPVRAGEN VAN DE PS? STAAT NIET EXPLICIET IN DE RICHTLIJN. 3.14.2.2 ProcesHet proces van deze usecase is:
3.14.2.3 PostprocesDe GGZ-hulpverlener is in staat om gegevens in te zien in het dossier van de huisarts en gebruikt de gegevens voor de behandeling van de patiënt. 3.14.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.14.4 InformatieoverdrachtZowel GGZ-hulpverleners als huisartsen maken gebruik van een informatiesysteem, respectievelijk:
3.14.4.1 Systemen & SysteemrollenDe GGZ-instelling en de huisarts maken ieder gebruik van een informatiesysteem, respectievelijk GGZ-informatiesysteem (XIS) en HuisartsInformatieSysteem (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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.14.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.15 Usecase: Wederzijds bericht Wijziging somatiek/therapie/controles huisarts <-> GGZVRAAG: DIT BERICHT WORDT DOOR ZOWEL DE HUISARTS ALS DOOR DE GGZ-HULPVERLENER GESTUURD: KAN DIT IN EEN USECASE?
3.15.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een bericht wijziging somatiek/therapie/controles. Dit bericht wordt door zowel de huisarts als de GGZ gebruikt om elkaar te informeren over tussentijdse veranderingen die interfereren met de ingestelde behandeling. Het gaat dan om een belangrijke wijziging in de medicatie, een complicatie van de behandeling of een nieuwe diagnose of episode. In het bericht doet de verzender ook een voorstel voor verdere behandeling en controle van de patiënt. 3.15.2 Proces en Context (pre- en postproces)3.15.2.1 PreprocesDe huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). 3.15.2.2 Proces
3.15.2.3 PostprocesDe huisarts/ GGZ-hulpverlener heeft het bericht ontvangen en gebruikt de ontvangen gegevens voor de behandeling van de patiënt. 3.15.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt.
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.15.4 InformatieoverdrachtZowel Huisartsen als GGZ-hulpverleners maken gebruik van een informatiesysteem, respectievelijk:
3.15.4.1 Systemen & SysteemrollenDe huisarts en de GGZ 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.
Zie ook onderstaande afbeelding: Afbeelding volgt.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.15.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven voor het sturen van het bericht wijziging somatiek/therapie/controles van de huisarts naar de GGZ: Afbeelding volgt.
In onderstaande afbeelding en tabel is dit schematisch weergegeven voor het sturen van het bericht wijziging somatiek/therapie/controles van de GGZ naar de huisarts: Afbeelding volgt.
3.16 Usecase: GGZ stuurt bericht kennisgeving patiënt heeft afspraak
3.16.1 Doel en RelevantieMet het bericht 'Kennisgeving patiënt heeft afspraak' bevestigt de GGZ aan de huisarts dat met de patiënt een intake-afspraak is gemaakt na verwijzing door de huisarts. Dit bericht bevat alleen administratieve en logistieke gegevens en bestaat dan ook alleen uit de envelop. Deze usecase beschrijft de reden van het versturen van dit bericht Kennisgeving patiënt heeft afspraak. 3.16.2 Proces en Context (pre- en postproces)3.16.2.1 Preproces
3.16.2.2 ProcesHet proces van deze usecase is:
3.16.2.3 Postproces
3.16.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.16.4 InformatieoverdrachtZowel GGZ-hulpverleners als huisartsen maken gebruik van een informatiesysteem, respectievelijk:
3.16.4.1 Systemen & SysteemrollenDe GGZ-instelling en de huisarts maken ieder gebruik van een informatiesysteem, respectievelijk GGZ-informatiesysteem (XIS) en HuisartsInformatieSysteem (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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.16.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.17 Usecase: GGZ stuurt bericht na intake naar huisarts
3.17.1 Doel en RelevantieMet het 'Bericht na intake' brengt de GGZ-hulpverlener de huisarts op de hoogte van de bevindingen uit de intake. Dit bericht wordt naar de huisarts verstuurd als reactie op de verwijzing, maar ook als de patiënt via een andere route door de GGZ gezien is. Dit bericht bestaat alleen uit een envelop en kern. Deze usecase beschrijft de reden van het versturen van het bericht na intake. In dit bericht zitten alle benodigde gegevens voor de GGZ om de patiënt te kunnen ontvangen en de behandeling te kunnen starten. 3.17.2 Proces en Context (pre- en postproces)3.17.2.1 Preproces
De huisarts mag de patiëntgegevens sturen zonder expliciete toestemming van de patiënt op basis van veronderstelde patiënttoestemming. Dit staat beschreven in de Wet op de geneeskundige behandelingsovereenkomst (WGBO). KLOPT DIT OOK BIJ EEN VERWIJZING NAAR DE GGZ STAAT NIET EXPLICIET IN DE RICHTLIJN? 3.17.2.2 ProcesHet proces van deze usecase is:
3.17.2.3 Postproces
3.17.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.17.4 InformatieoverdrachtZowel Huisartsen als GGZ-hulpverleners maken gebruik van een informatiesysteem, respectievelijk:
3.17.4.1 Systemen & SysteemrollenDe huisarts en de GGZ 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.17.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.18 Usecase: GGZ stuurt bericht Kennisgeving overdracht behandeling naar GGZ
3.18.1 Doel en RelevantieDe Kennisgeving overdracht behandeling wordt verstuurd na overdracht van de behandeling naar een andere afdeling binnen de GGZ-instelling. Deze usecase beschrijft de reden van het versturen van het bericht na intake. In dit bericht zitten alle benodigde gegevens voor de GGZ om de patiënt te kunnen ontvangen en de behandeling te kunnen starten. 3.18.2 Proces en Context (pre- en postproces)3.18.2.1 PreprocesDe GGZ-hulpverlener gaat een bericht Kennisgeving overdracht behandeling sturen naar een collega GGZ-hulpverlener. 3.18.2.2 ProcesHet proces van deze usecase is:
3.18.2.3 Postproces
3.18.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.18.4 InformatieoverdrachtZowel Huisartsen als GGZ-hulpverleners maken gebruik van een informatiesysteem, respectievelijk:
3.18.4.1 Systemen & SysteemrollenDe huisarts en de GGZ 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.18.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.19 Usecase: GGZ stuurt bericht voortgang naar de huisarts
3.19.1 Doel en RelevantieTijdens een behandeling met een langdurig karakter stuurt de GGZ ten minste eenmaal per jaar een bericht over de voortgang. Het Bericht 'voortgang' is doorgaans veel korter dan het uitgebreide bericht einde behandeling. Dit heeft te maken met het aantal rubrieken dat wordt ingevuld. Deze usecase beschrijft de reden van het versturen van het bericht voortgang. In dit bericht zitten alle benodigde gegevens voor de GGZ om de patiënt te kunnen ontvangen en de behandeling te kunnen starten. 3.19.2 Proces en Context (pre- en postproces)3.19.2.1 Preproces
3.19.2.2 ProcesHet proces van deze usecase is:
3.19.2.3 Postproces
3.19.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.19.4 InformatieoverdrachtZowel Huisartsen als GGZ-hulpverleners maken gebruik van een informatiesysteem, respectievelijk:
3.19.4.1 Systemen & SysteemrollenDe huisarts en de GGZ 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.19.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.20 Usecase: GGZ stuurt bericht einde behandeling naar huisarts
3.20.1 Doel en RelevantieHet 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. 3.20.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. 3.20.2.1 PreprocesEr zijn geen precondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een huisarts. 3.20.2.2 ProcesHet proces van deze usecase is:
3.20.2.3 PostprocesEr zijn geen postcondities of voorwaarden van toepassing voor het sturen van een ontslagbericht aan een huisarts. 3.20.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.20.4 InformatieoverdrachtZowel GGZ-instellingen als huisartsen maken gebruik van een informatiesysteem, respectievelijk:
3.20.4.1 Systemen & SysteemrollenDe 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.20.4.2 Transacties & TransactiegroepenHet 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 usecase.
3.20.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepenOnderstaande 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: Afbeelding volgt.
3.21 Usecase: Huisarts verwijst naar ketenzorgpartner
3.21.1 Doel en RelevantieDe huisarts verwijst de patiënt naar de ketenzorgpartner zodat zorg ten behoeve van Diabetes, COPD, CVRM en/ of ouderenzorg kan worden geboden. Deze usecase beschrijft de reden van het versturen van het verwijsbericht. In dit verwijsbericht zitten de gegevens van de envelop en de kern zoals gespecificeerd in de HASP-richtlijn. Dit bericht dient ook als een aanwijzing voor de ketenzorgpartner om de benodigde dossiergegevens te kunnen ophalen uit het HIS. Op deze manier kunnen door de ketenzorgpartner de dossiergegevens worden opgehaald op het moment dat de verwijzing wordt opgepakt. Hiermee zijn de meest actuele gegevens voor de ketenzorgpartner beschikbaar. Het apart ophalen van de dossiergegevens valt functioneel nog steeds onder de verwijzing. De huisarts blijft de verantwoordelijke voor de zorg van de patiënt. Indien de huisarts de verwijzing wil annuleren, stuurt de huisarts hetzelfde verwijsbericht, met de status geannuleerd. In het voorgaande functioneel ontwerp voor ketenzorg was dit een aparte usecase, maar met deze opzet komt deze te vervallen. 3.21.2 Proces en Context (pre- en postproces)3.21.2.1 Preproces
3.21.2.2 ProcesHet proces van deze usecase is:
3.21.2.3 PostprocesDe ketenzorgpartner heeft het verwijsbericht en de dossiergegevens ontvangen van de huisarts en gebruikt deze gegevens voor de behandeling van de patiënt. 3.21.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.21.4 InformatieoverdrachtZowel Huisartsen als Ketenzorgpartners maken gebruik van een informatiesysteem, respectievelijk:
3.21.4.1 Systemen & SysteemrollenDe huisarts en de ketenzorgpartner maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ketenzorginformatiesysteem (KIS). Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen in het kader van het sturen van het verwijsbericht naar de ketenzorgpartner mogelijk maken. In ART-DECOR worden de systeemrollen als Actor beschreven.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.21.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.22 Usecase: Ketenzorgpartner stuurt eindrapportage naar huisarts
3.22.1 Doel en RelevantieDeze usecase beschrijft de reden van het versturen van een eindrapportage door de ketenzorgpartner naar de huisarts. De eindrapportage wordt gestuurd bij de afsluiting van de behandeling, onafhankelijk van de reden hiervoor. De eindrapportage bevat inzicht in de gegeven behandeling door de ketenzorgpartner en het resultaat daarvan. Met het versturen van de eindrapportage wordt het ketenzorgtraject afgesloten. 3.22.2 Proces en Context (pre- en postproces)3.22.2.1 PreprocesDe ketenzorgpartner heeft de zorg zodanig geleverd dat de doelstellingen van het individueel zorgplan zijn behaald. 3.22.2.2 ProcesHet proces van deze usecase is:
3.22.2.3 PostprocesDe huisarts verwerkt de gegevens uit de eindrapportage in het dossier van de patiënt. 3.22.3 Bedrijfsrollen en UML activity diagram
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren: Afbeelding volgt. 3.22.4 InformatieoverdrachtZowel Huisartsen als Ketenzorgpartners maken gebruik van een informatiesysteem, respectievelijk:
3.22.4.1 Systemen & SysteemrollenDe huisarts en de ketenzorgpartner maken ieder gebruik van een informatiesysteem, respectievelijk Huisartseninformatiesysteem (HIS) en Ketenzorginformatiesystemen (KIS). 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.
Zie ook onderstaande afbeelding: Afbeelding volgt. 3.22.4.2 Samenhang bedrijfsrollen, transacties, systeemrollen en transactiegroepenHet uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, waarbij een verzameling van bij elkaar horende transacties een transactiegroep vormt. Elke usecase bestaat uit de volgende verbanden:
In onderstaande afbeelding en tabel is dit schematisch weergegeven: Afbeelding volgt.
3.23 Usecase: Patiënt raadpleegt dossier huisartsgegevensNote: zie MedMij
3.23.1 Doel en Relevantie3.23.2 Proces en Context (pre- en postproces)3.23.2.1 Preproces3.23.2.2 Proces3.23.2.3 Postproces3.23.3 Bedrijfsrollen en UML activity diagram
3.23.4 Informatieoverdracht3.23.4.1 Systemen & Systeemrollen3.23.4.2 Transacties & Transactiegroepen3.23.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.24 Usecase: Huisarts stuurt vragenlijst aan patiëntNote: Huisarts zet vragenlijst klaar voor patiënt
3.24.1 Doel en Relevantie3.24.2 Proces en Context (pre- en postproces)3.24.2.1 Preproces3.24.2.2 Proces3.24.2.3 Postproces3.24.3 Bedrijfsrollen en UML activity diagram
3.24.4 Informatieoverdracht3.24.4.1 Systemen & Systeemrollen3.24.4.2 Transacties & Transactiegroepen3.24.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.25 Usecase: Patiënt stuurt antwoorden op vragenlijst aan huisarts
3.25.1 Doel en Relevantie3.25.2 Proces en Context (pre- en postproces)3.25.2.1 Preproces3.25.2.2 Proces3.25.2.3 Postproces3.25.3 Bedrijfsrollen en UML activity diagram
3.25.4 Informatieoverdracht3.25.4.1 Systemen & Systeemrollen3.25.4.2 Transacties & Transactiegroepen3.25.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.26 Usecase: Patiënt stuurt zelfmeting aan huisartsNote: Nog geen richtlijn beschikbaar
3.26.1 Doel en Relevantie3.26.2 Proces en Context (pre- en postproces)3.26.2.1 Preproces3.26.2.2 Proces3.26.2.3 Postproces3.26.3 Bedrijfsrollen en UML activity diagram
3.26.4 Informatieoverdracht3.26.4.1 Systemen & Systeemrollen3.26.4.2 Transacties & Transactiegroepen3.26.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen3.27 Usecase: Patiënt raadpleegt afspraak bij huisartsNote: de tijd van de afspraak
3.27.1 Doel en Relevantie3.27.2 Proces en Context (pre- en postproces)3.27.2.1 Preproces3.27.2.2 Proces3.27.2.3 Postproces3.27.3 Bedrijfsrollen en UML activity diagram
3.27.4 Informatieoverdracht3.27.4.1 Systemen & Systeemrollen3.27.4.2 Transacties & Transactiegroepen3.27.4.3 Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen |
4 Release notes
In onderstaande tabel staan de wijzigingen voor dit ontwerp:
Versie | BITS-ticket | Omschrijving |
---|---|---|
0.2.0-beta.1 | ELZT-93 | The profiles contained several slices on elements with a maximum cardinality of 1 which is not allowed by the FHIR spec, those slices have been removed. |
ELZT-83 | Add reference to the BSeR FHIR IG to indicatie that Nictiz uses it as inspiration and participate in the development. | |
ELZT-81 | The term "paramedic" is not a correct translation for the Dutch word "paramedicus". This has been changed to "allied health professional". | |
ELZT-80 | The slicing of hg-ReferralComposition has been changed in order to align with the structure of the data set. The .section elements have been sliced to "envelope" (Envelop) and "core" (Kern). The data set concepts from the aforementioned sections have been moved to slices inside those sections. SNOMED-codes are assigned to sections "core" and "envelope" to identify the content, see https://bits.nictiz.nl/browse/TER-17 for more information. The code for section requiredConsultationFacilities has been changed to 230211000146109. | |
ELZT-78 | To support future workflow and align with BSeR, the FHIR Task resource is added to the FHIR IG and a designated Task profile is created: hg-ReferralTask. | |
ELZT-76 | The .status element of the ServiceRequest examples has been changed to "completed" and extra guidance is added on the .status element in the hg-ReferralServiceRequest profiles. | |
ELZT-75 | Several small textual changes for the ELZ functional design and FHIR IG. | |
ELZT-72 | Add CapabilityStatement for the use case "Referral from general practitioner to allied health professional". | |
ELZT-71 | "EersteLijnsZorg" (CamelCased) has been changed to "Eerstelijnszorg". | |
ELZT-70 | Omdat de FHIR-profielen voor de zib2020-publicatie nog niet definitief uitgebracht zijn, is dit kenbaar gemaakt op zowel het functioneel ontwerp als de FHIR IG. | |
ELZT-69 | Updated the nl-core package dependency to version 0.9.0-beta.1. | |
ELZT-65 | Tekstuele wijzigingen in het functioneel ontwerp: "Actuele dossiergegevens" is aangepast naar "gegevens op moment van verwijzen". De tekst over het verwijderen van eerder ontvangen gegevens bij het annuleren van een verwijzing is verwijderd. De beschrijving over ophalen van Dossiergegevens is verwijderd. Nieuwe inzichten hebben ertoe geleid dat de Dossiergegevens samen met de Envelop en Kern worden verstuurd. In dat kader zijn de zinnen "Beschikbaar stellen door de huisarts" en "Raadplegen door de paramedicus" verwijderd. NB Dossiergegevens zijn geen onderdeel van deze release. | |
ELZT-63 | The FHIR ValueSet RequestPriority is linked to the element "Envelop.Urgentie" in ART-DECOR. The changed description for this element has been included in the hg-ReferralServiceRequest profile. | |
ELZT-62 | Tekstuele wijzigingen in het functioneel ontwerp: "arts" vervangen door "huisarts". | |
ELZT-61 | Tekstuele wijziging in de omschrijving van het element Kern.RedenBericht: "Geeft de reden van de verwijzing of de update. Hierbij is de beschrijving als vrije tekst op aangeven van het NHG verplicht. Daarnaast kan er ook een ICPC-code van de episode worden meegestuurd, al dan niet aangevuld met meer details over de vastlegging van de ICPC." | |
ELZT-59 | Clarification on how to deal with .text (narrative) in a Composition.section without an .entry is added to the ELZ FHIR IG. | |
ELZT-50 | Tekstuele wijziging in ART-DECOR: in de omschrijving van de transactie is "medisch specialist" vervangen door "paramedicus". | |
0.1.0-alfa.2 | ELZT-12 | Missende afbeelding toegevoegd op het Functioneel Ontwerp, verwijzing naar gepubliceerd ART-DECOR-scenario toegevoegd op het Functioneel ontwerp, mappings in FHIR-profielen aangepast naar gepubliceerd ART-DECOR scenario. Diverse kleine (tekstuele) wiki-wijzigingen doorgevoerd. |
0.1.0-alfa.1 | ELZT-1 | Versie 0.1.0-alfa.1 van ELZ. |