Geverifieerd, GeverifieerdBij en Verificatiedatum - aanpassingen
Zorginf. bouwsteen (oud)
Fix versions
Parent
Description
Proposed solution (NL)
De term van de container 'Geverifieerd' wijzigen in 'AfgesprokenMet'
De cardinaliteit van de container 'AfgesprokenMet' is 1..*
Alle data-items en de codelijst onder de container 'Geverifieerd' in het oude model zijn vervallen. In plaats daarvoor komen er twee context references naar twee zibs:
Patiënt
Contactpersoon
Middels deze modellering worden meerdere wijzigingsvoorstellen adequaat beantwoord. Omdat een zib geen chronologie behoort te bevatten - immers een logisch model - vervalt de noodzaak voor 'Verificatie'. Issue ZIB-1022 is met deze voorgestelde oplossing ook geheel afgehandeld.
Release notes (NL)
De term van de container 'Geverifieerd' gewijzigd in 'AfspraakPartij'
De cardinaliteit van de container 'AfspraakPartij' is 2..*
Alle data-items en de codelijst onder de container 'Geverifieerd' in het oude model zijn vervallen. In plaats daarvoor zijn er drie context references naar twee zibs: Patiënt, Contactpersoon en Zorgverlener.
Attachments
duplicate of
is related to
Activity

Jeroen Windhorst July 1, 2020 at 11:39 AM
Reactie consultatieronde door UMCG (Michael vd Zel):
Er wordt gesproken over de container “Geverifieerd”, maar die bestaat helemaal niet. Wordt hier “Verificatie” bedoeld?
Reactie functioneel beheerder zib centrum:
(overnemen)

Jeroen Windhorst July 1, 2020 at 11:28 AM
Reactie consultatieronde door Epic (Cliff Wu):
Eens. Wel een commentaar dat een wijziging van kardinaliteit van 0..1 naar 1..* vrijwel invloed heeft op de leveranciers kant waarmee er een verandering op database niveau wordt vereist. In dit geval kunnen wij hierin vinden. Dit is makkelijker dan andersom. 1..*/meerdere waardes terugbrengen naar slechts één waarde is dikwijls een grote database verandering en heeft ook impact in de praktijk om afspraken te maken over hoe met historisch gegevens om te gaan.
Reactie functioneel beheerder zib centrum:
(nadere toelichting)

Richard Westerhof April 24, 2020 at 11:42 AM
Akkoord

Bas de Jong April 23, 2020 at 10:02 AMEdited
Na overleg: MeestRecenteBespreekdatum blijft het.
Redenatie: deze term dekt de lading van wat er met deze datum wordt bedoeld; of het nu een nieuwe BA is of een reeds opgestelde BA maar is zonder wijzigingen besproken; vanaf de ingevoerde datum geldt deze BA. In het geval er twee BA's zijn geregistreerd, kan men a.d.h.v. deze datum bepalen welke het meest recent is en dus moet worden aangehouden. Als je het dan hebt over een 'begindatum' van een BA kan het best zijn dat er later nog een bespreking hierover is geweest - dat is met deze term niet duidelijk.
Actualisatie wordt het ook niet; dit kan suggereren dat het een andere datum zijn dan de datum van de bespreking.

Bas de Jong April 21, 2020 at 2:37 PM
N.a.v. Overleg met Richard en Albert-Jan:
Het voorgestelde model zoals nu is ontworpen - en daarbij het weglaten van een verificatie - is besproken en in overeenstemming.
Punt van discussie is welke term er gebruikt moet worden voor de datum waarop een behandelaanwijzing tussen een arts en patiënt is afgesproken en vastgelegd.
Bespreekdatum of afspraakdatum
Meest recente bespreekdatum of afspraakdatum
Start/begindatum
Actualisatiedatum
Voorstel is om dit met Astrid van Ginneken te bespreken
Details
Assignee
Albert-Jan SpruytAlbert-Jan SpruytReporter
Bas de JongBas de JongClassification
Minor (Y)Components
Priority
Undefined
Details
Details
Assignee

Reporter

Dit issue omvat meerdere NHG wijzigingsissues en zijn alhier samengebracht omdat deze direct verband houden met elkaar. Hieronder zijn elk van de NHG issues verder toegelicht:
Verificatiedatum en Laatste Bespreekdatum.
NHG: Verificatie is niet compleet expliciet gemodelleerd in het HIS referentiemodel. Dit lijkt ook niet noodzakelijk, op een expliciete laatste bespreekdatum na; in principe moeten behandelgrenzen periodiek geactualiseerd worden.
Op dit moment is binnen het HIS Referentiemodel een verificatiemoment gemodelleerd als laatste Bespreekdatum. Deze attributen lijken hetzelfde doel te hebben, namelijk aangeven wanneer de behandelbeperking voor het laatst besproken en dus verifieerd is. Laatste bespreekdatum dekt daarbij beter de lading. Verificatiedatum kan suggereren dat dit alleen om een verificatie na een initiële vaststelling gaat. Ook geeft verificatie onvoldoende aan wat geverifieerd wordt. Daarbij wordt in sommige contexten verificatie gebruikt om een eenzijdige verificatie te duiden. Dit wordt hier expliciet niet bedoeld.
Deze informatie wordt dusdanig belangrijk geacht voor de interpretatie van de behandelbeperking, dat de cardinaliteit 1 moet zijn.
GeverifieerdBij
NHG: De term doet nu vermoeden dat het om een verificatie gaat na de initiële vaststelling. Dit is echter niet hoe dit attribuut bedoeld is. In dit attribuut wordt aangegeven met wie de afspraak van de behandelbeperking is gemaakt. Dit is van belang omdat het niet in alle gevallen de patiënt zelf zal zijn en in tussen een verandering opgetreden kan zijn in de bewindvoering. De cardinaliteit is 0..1 omdat voorzien wordt dat zorgverleners niet geneigd zullen zijn om het attribuut in te vullen wanneer de afspraak met de patiënt zelf is gemaakt. Tot slot wordt het attribuut een vrij tekstveld, zodat de zorgverlener zelf aan kan geven met wie de behandelgrens afgesproken is. De reden hiervoor is dat de huidige codelijst te beperkt is, nuance van belang wordt geacht, het kan voorkomen dat een zorgverlener zowel rol als persoon wil kunnen duiden en tot slot wordt verwacht dat een keuzelijst een extra hobbel bij implementatie kan opleveren.
Geverifieerd
NHG: Tot een behandelgrens wordt gezamenlijk door de eindverantwoordelijk arts en de patiënt (of diens vertegenwoordiger) besloten. Dit betekent dat een behandelgrens niet wordt genoteerd, voordat dit besproken en besloten is met de patiënt of diens vertegenwoordiger. Het attribuut “geverifieerd” is overbodig.
#NHGHarmonisatie