All technical FAQ related to dematerialisation initiative.

All Technical FAQ related to Validity Period.

Usefull Links on the validity period

All FAQ related to SAM V2

Usefull links on SAM V2

All FAQ related to Regulation

Usefull links

Tech-Demat-Regulation (21)

For your information

Delphicare will adapt to the SAMV2 requirements

The detailed description that contains the date (day) of creation is explicitly written out in 4.7; for efficiency of Recip-e it is important that the creation month can be derived from the “extension”, so that you can immediately look into the correct monthly table.

MGuid is used for tracebility reasons – unique identifier that is included in all internal technical transactions concerning this regulation

Digital RID is also expected to be much more extended, which allows also much less printing. Printing RID should not be encouraged. Digital RID (if there is a possibility to digitalize this) can be encouraged.
There is a big dependency of the patientplatforms that will be setting the visiflags and ensure some guarantee/ choices on privacy of the prescriptions. As long as these are not created (we do not know the exact dates), we need to lock the digital access to Recip-e by the pharmacist.
Be Careful! Until the visiflags are implemented all prescriptions without flags will be set on “locked” to open based on INSZ functions (ListRelations, ListOpenPrescriptions, ListRidsHistory). As such we are sure that the privacy choice of the patient is met.
Afterwards, when the flags are developed/ implemented, they can have the status as provided in the specifications.

A proof of electronic prescription is giving all the information. If a patient requests this info, it can be that he prefers that the pharmacists accesses the prescription by RID, so all info is needed.

This is the patient allowing a third person as a mandatee to get the pharmaceutical products at the pharmacy. Only the patient can set this function through the (to be developed) patient platform.

See presentation slides (timeline). Indeed we also need to have the V4 bus of ehealth to be ready before testing can occur.

Error codes will be provided by Recip-E, the error handling should be developed in the softwarepackage.

Mguid should be logged and provided when contacting the servicedesk.

Yes, we want to exclude the risk of collusion between Dr/ Pharmacist.

We will provide communication to both patient and prescriber (who eventually has to go fully digital for e-prescriptions)

The therapeutic relation is to be set up with the pharmacist with a purpose to deliver the pharmaceutical product.

In most cases it will be a package (CNK-code), exceptions to be further clarified by RIZIV.

V1.28 was provided – Kmehr V1.28 => SV=”1.29″

The purpose of “GETANDMARKASDELIVERED” is that after the closure of the sales at the pharmacy, some actions are taken together to put the prescriptions in the right status “delivered” and in the background “archived”.

This function will be provided by the patient platform. The patient reserves the prescriptions, and a notification is sent tot he pharmacy the patient indicates. This is just a sign. When the sale is closed, the same process as normal is being used.

The RID is always for a certain patient. It is a mandated person that can get the pharmaceutical products at the pharamcist, if he has the access tools (RID, e-ID à see decision tree).

Listrelations is necessary to check if a third person is really mandated. A pharmacist can only legally open the list of prescriptions if this third person is proven to have a mandate (which is normally indicated by the patient through the patient platform).

Yes, a therapeutic relationship is necessary for the list function.

The visi-flag does NOT override the therapeutic relationship, so a therapeutic relationship has to be established first.

Recip-E does not provide any functions for this. Best check
https://www.mijngezondheid.belgie.be/#/

Stay tuned on technical FAQ updates!