A0045- Evalueren medische informatie

Header Image
Project:
Het evalueren van medische informeren is ruimer dan enkel maar genesmiddelen en gezondheidsproducten.<br/>Business Process Case 1 - Raadplegen van leeg gedeeld Medicatieschema<br/>Beschrijving van de specifieke kenmerken:<br/>Wanneer een patiënt voor de eerste keer een voorschrijver raadpleegt is zijn Medicatieschema nog leeg. De voorschrijver zal dit niet altijd vooraf weten. Wanneer de voorschrijver via zijn pakket een patiënt opzoekt die nog geen medicatie lijnen heeft in zijn Medicatieschema, dan moet het pakket van de voorschrijver dit ook zo<br/>- 55 -<br/>P 55 / 235<br/>tonen en de mogelijkheid bieden om een Medicatieschema aan te maken. De voorschrijver zal in zijn pakket een nieuwe patiënt aanmaken, de basisgegevens (identificatiegegevens, contactgegevens) van de patiënt registreren en daarnaast ook de medische historiek van de patiënt toevoegen. De arts moet hierbij rekening houden met de principes van de minimale gegevensverwerking, proportionaliteit en noodzakelijkheid. +++ Opmerking 58 - Zie het advies van de nationale raad van 20 maart 2021 (a168007) +++<br/>Er is dus een onderscheid tussen een patiënt die al wel een Medicatieschema heeft en die voor de eerste keer bij een bepaalde voorschrijver komt, en een patiënt die helemaal nog geen Medicatieschema heeft en ook voor de eerste keer bij een bepaalde voorschrijver komt. In het eerste geval zal de voorschrijver in zijn eigen pakket een dossier aanmaken en de bestaande medicatie lijnen en andere gegevens in het Medicatieschema synchroniseren met zijn pakket. In het tweede geval, zoals hierboven beschreven in Business process case 1: Raadplegen van een leeg gedeeld Medicatieschema. +++ Opmerking 59 - Jeroen De Wilde: te corrigeren: business process case 1 = raadplegen van leeg gedeeld medicatieschema +++<br/>In het geval de patiënt een Medicatieschema heeft in een andere kluis, wordt de interkluizen flow gebruikt om gegevens op te halen. Dit principe moet uitgebreid worden naar alle data-elementen (ook journaalnotities,…).<br/>Indien de patiënt verhuist, dan zullen de gegevens van het Medicatieschema mee verhuizen naar dezelfde regio.<br/>Business Process Case 2 - Raadplegen van een niet leeg gedeeld Medicatieschema<br/>Beschrijving van de specifieke kenmerken:<br/>Er zijn verschillende doelgroepen die toegang moeten hebben tot het Medicatieschema. Naast de voorschrijvers, de apothekers en andere zorgverleners is er uiteraard de patiënt en zijn entourage. Verder zijn er zorginstellingen zoals ziekenhuizen en Woonzorgcentra (WZC).<br/>Voorschrijvers en artsen in het bijzonder, zullen zelden of nooit het Medicatieschema op zich raadplegen, maar dit altijd bekijken vanuit de Medication Folder View (MFV). Dit is een overzicht met niet alleen de Medicatielijnen maar ook Journaal notities, voorschriften en andere gegevens, zoals bv (maar niet beperkt tot) contracten met betrekking tot rationaal geneesmiddelengebruik +++ Opmerking 60 - Robert Vander Stichele: welke contracten zijn dit? ( Het gaat hier om contracten die afspraken rond het gebruik van bv benzodiazepines en opioiden vasstleggen tussen onder andere patiënt en arts. +++ .<br/>- 56 -<br/>P 56 / 235<br/>Wanneer een gedeeld Medicatieschema in de kluis door een voorschrijver geraadpleegd wordt, wordt dit ook in twee richtingen gesynchroniseerd met de Medicatielijnen die lokaal worden bijgehouden in het pakket van de voorschrijver.<br/>Business Rules<br/>De business rules in dit document moeten afgetoetst worden aan en aangevuld worden met de business rules beschreven in een werkdocument dat in het kader van Werkgroep 2 binnen het TRIO-overleg wordt opgemaakt. Dit document is nog niet gepubliceerd.<br/>BR1 - De medicatie lijnen in het gedeeld Medicatieschema van de patiënt, zijn bij elk bezoek aan een voorschrijver verplicht te synchroniseren met zijn pakket.<br/>BR2 - Journaal notities die in het gedeeld Medicatieschema bijgehouden worden en die door een arts de status gekregen hebben van medische informatie, zijn bij elk bezoek aan een voorschrijver verplicht te synchroniseren met zijn pakket. +++ Opmerking 61 - Hans De Keersmaecker: Op dit ogenblik is dit nog onduidelijk hoe de journaal notities in combinatie met het schema gebruikt gaan worden. Als bv een journaalnotitie behandeld is, gaat die dan een nieuwe status krijgen? Wat geeft nu aan dat het medische informatie is? Is dat puur de medicatie tag? ( Het is de bedoeling dat een tag kan aangeven of informatie in een journaalnotitie, als medische informatie kan beschouwd worden. Daartoe bekijkt en beoordeelt de arts, eventueel de apotheker, de informatie naar relevantie, correctheid, bruikbaarheid,…. +++ +++ Opmerking 62 - Recip-e: De patiënt kan in journaalnotities ook medisch niet-gevalideerde informatie opnemen, hoe moeten andere gebruikers hiermee omgaan? ( Juist en de informatie kan ook onvolledig zijn. Voor VIDIS fase II moet daarom een statuscode “medisch gevalideerd” toegevoegd worden die aangeeft dat een voorschrijver of in bepaalde gevallen een apotheker die kwalificatie kan even. +++<br/>Specifieke gebruikers:<br/>• De voorschrijver is beheerder van het EPD<br/>De arts die ook het EPD beheert, zal naast het synchroniseren van het gedeeld Medicatieschema met zijn eigen pakket, ook bekijken of gegevens, die niet verplicht gesynchroniseerd worden volgens de business rules, toch ook moeten overgebracht worden. Dit kan in twee richtingen: van zijn pakket naar het gedeeld Medicatieschema in de kluis of omgekeerd. We denken hier bijvoorbeeld aan de journaalnotities of de status van een journaalnotitie.<br/>De arts roept het gedeeld Medicatieschema van de patiënt op vanuit zijn pakket. Hij gebruikt hiervoor eventueel naam en voornaam van de patiënt, maar de basis om gegevens uit te wisselen met de kluis, blijft het rijksregisternummer of equivalent (zie bis- en ternummers).<br/>• De voorschrijver is de enige voorschrijver in het Medicatieschema<br/>- 57 -<br/>P 57 / 235<br/>• De voorschrijver is niet de enige voorschrijver in het Medicatieschema<br/>• De voorschrijver werkt op verplaatsing<br/>• De gebruiker is een apotheker<br/>• De gebruiker is een ziekenhuis (voorschrijver (arts specialist), verpleegkundige, ziekenhuisapotheker)<br/>• De gebruiker is een Woonzorgcentrum (CRA, verpleegkundige, verantwoordelijke toediening)<br/>• De gebruiker is een thuisverpleegkundige<br/>• De gebruiker is een patiënt<br/>• De gebruiker is een naaste van de patiënt<br/>• De gebruiker is een volmachthouder<br/>o Voorschriften volmacht<br/>o Zorgvolmacht<br/>
Modified: 15/05/2024 10:52:05
ID: {6EF9F2BD-CEA2-4496-99AD-EA3F53574399}
>Appears In: Processen E2E Medicamenteuze behandeling
  • Flow To
  • Flow From
  • Tagged Values
  • Advanced
Element Name
A0019- Behandeling Patient
Activity «SequenceFlow»
 
Details:
 
Element Name
A0062- Inschrijven Patient
Activity «SequenceFlow»
 
Details:
 
Tag Value
activityType Task
Details:
Values: Task,Sub-Process
Default: Task
adHoc false
Details:
Values: true,false
Default: false
adHocOrdering Parallel
Details:
Values: Parallel,Sequential
Default: Parallel
behavior All
Details:
Values: None,One,All,Complex
Default: All
cancelRemainingInstances true
Details:
Values: true,false
Default: true
completionQuantity 1
Details:
Default: 1
implementation ##unspecified
Details:
Values: ##webService,##unspecified
Default: ##unspecified
instantiate false
Details:
Values: true,false
Default: false
isACalledActivity false
Details:
Values: true,false
Default: false
isATransaction false
Details:
Values: true,false
Default: false
isForCompensation false
Details:
Values: true,false
Default: false
isSequential false
Details:
Values: true,false
Default: false
loopCharacteristics None
Details:
Values: None,Standard,MultiInstance
Default: None
startQuantity 1
Details:
Default: 1
state None
Details:
Values: None,Ready,Active,Cancelled,Aborting,Aborted,Completing,Completed
Default: None
taskType Abstract
Details:
Values: BusinessRule,Manual,Receive,Service,Send,Script,User,Abstract
Default: Abstract
testBefore false
Details:
Values: true,false
Default: false
triggeredByEvent false
Details:
Values: true,false
Default: false
Property Value
_tagGroupings: auditing=Base Element;categoryValue=Base Element;documentation=Base Element;monitoring=Base Element;activityType=Activity;calledActivityRef=Activity;instantiate=Activity;isACalledActivity=Activity;isATransaction=Activity;isForCompensation=Activity;resources=Activity;messageRef=Task;operationRef=Task;rendering=Task;script=Task;scriptFormat=Task;taskType=Task;adHoc=AdHoc;adHocOrdering=AdHoc;cancelRemainingInstances=AdHoc;completionCondition=AdHoc;behavior=Loop;complexBehaviorDefinition=Loop;isSequential=Loop;loopCardinality=Loop;loopCharacteristics=Loop;loopCondition=Loop;loopCounter=Loop;loopDataInputRef=Loop;loopDataOutputRef=Loop;loopMaximum=Loop;noneBehaviorEventRef=Loop;oneBehaviorEventRef=Loop;testBefore=Loop;transactionMethod=Sub-Process;transactionProtocol=Sub-Process;triggeredByEvent=Sub-Process;ioBinding=Callable Element;ioSpecification=Callable Element;supportedInterfaceRefs=Callable Element;actualOwner=Execution;completionQuantity=Execution;implementation=Execution;numberOfActiveInstances=Execution;numberOfCompletedInstances=Execution;numberOfInstances=Execution;numberOfTerminatedInstances=Execution;startQuantity=Execution;state=Execution;taskPriority=Execution;assignments=Other;sub-ProcessRef=Other;definitionalCollaborationRef=Sub-Process;
_tagGroups: Base Element,Activity,Task,AdHoc,Loop,Sub-Process,Callable Element,Execution,Other
_subtypeProperty: BPMN2.0::Activity::taskType
_tagGroupStates: Base Element=closed;Activity=open;Task=open;AdHoc=closed;Loop=closed;Sub-Process=closed;Callable Element=closed;Execution=closed;Other=closed;
_defaultDiagramType: BPMN2.0::Business Process
isReadOnly: false
isFinalSpecialization: 0