All technical FAQ related to dematerialisation initiative.

All Technical FAQ related to Validity Period.

Usefull Links on the validity period

Tech-Demat-ValidityPeriod (5)

a. Can it still be collected by means of the RID?
Answer: no

b. Is this the overview of the reservations (ListReservations)
Answer: Reservation is a status as set by a visi-flag by the patient, and only then possible to be listed, with the function ListReservations. If the RID is expired, the prescription will no longer be active on the Recip-e server, and thus not possible to list.

c. Is this in the list of the ListOpenPrescriptions
Answer: no. This prescription is no longer in “open” status to get an action.

The pharmaceutical product can not be OBTAINED FROM RECIP_E SO CERTAINLY NOT delivered. The patient needs to go back to his medical Doctor or you can phone him/ her to ask for a new prescription which you might also get access to digitally if there is a therapeutic relation (patient has e-ID with him/ her).

For medication it is still possible to indicate the “startdate” in a specific field. Ex. for abuses, mental illnesses, …. there might be reasons to delay the delivery.

Yes, the creation date is the base date (day to day) to calculate the expiration date of a prescription.

This is not possible. They will no longer be available on the Recip-e servers.

All FAQ related to SAM V2

Usefull links on SAM V2

Tech-Demat-SAM (2)

You can find a Reimbursable tag on each product in the SAMV2 database.

Categorie: Tech-Demat-SAM

We get our information through RIZIV. You will probably get your information as well through RIZIV. The moment we have more information, we will come back to you. As far as we were informed, it seems that the information will come up soon now.

Categorie: Tech-Demat-SAM

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

Stay tuned on technical FAQ updates!