Open dvribeira opened 5 months ago
The issue was brought to discussion to a meeting on 2024.04.30 including HCPs from HUG (L-Z. Kaestli) and CHUV (F. Bastardot and C. Galland) as well as a representative from eHealth Suisse (P. Jolo).
The consensus was that indeed the current representation might induce error. It was questioned how the eMediplan PDF format addresses the issue. The eMediplan PDF specification states the following:
No particular screenshot of an eMediplan addressing this specific case was found on-line.
Given the following dosage case:
An eMediplan PDF would have a row similar to the following:
But with the instructions containing 2 tablets per day as patient instructions.
So for the PMP I guess it is down to, without excluding any other ideas that might pop up, a choice between:
1) Either we do as the eMediplan PDF and do not display any information on the space dedicated to the morning-noon-etc. columns and the PDF generator adds this information to the patient instructions (e.g. 2 tablets per day). 2) Or we build on the current solution and try to make it clearer, for instance by adding _per_day after the provided quantity [and unit]. We might also indent it and wrap it in special characters to make it even clearer, e.g.: 2 tablet every day
I am not a big fan of the 1st one as an automatic way of working and will open new questions for instance: where should this be added if other instructions or comments are present? First? Last? Also, repetitions (redundant information) and contradictions in relation to the patient instructions cannot be avoided, but this is already the case. Also against it: this is a waste of a lot of space. If we want to be able to present many medications in one page (and we should strive for that as much as possible), this kind of waste should be avoided if possible. Furthermore, support for retrieving the PMLC in eMediplan format is foreseen, so perhaps there is no added value in having two identical PDF formats.
As reported by Oracle some months ago - thanks @CheriGey !-.
Any changes will normally have to be performed in husky, but we should collectively agree on the desired solution, hopefully with professional input. On the aggregator team side, this is low priority for now since we have to focus on the development of the aggregator at this point to avoid blocking other actors but we would hope that a consensus is reached before June so that the PDF generation can be updated before/if we start a pilot program.
Other currently open tasks/questions for the PDF generation are: