Caresets Medication scheme Business document RIZIV/INAMU

[KarlienHL7Belgium]

20241001 Caresets MedicationSchema V1.1 FR.docx

[pablocorilus]

@KarlienHL7Belgium
@costateixeira
Here are the comment till 1.6, awaiting the dutch document to read further
Remarks for 1.4.1 Version:
In other care sets, the version is typically included in the metadata. Could you explain why this is handled differently here? Consistency in how versioning is applied across care sets would help ensure clarity and uniformity in the schema. I recommend revisiting this approach to align it with practices in other care sets unless there is a specific justification for this deviation.
Remarks for 1.4.1 Recorder:
Item FHIR: InformationSource
The use of the InformationSource field may be incorrect. Based on the FHIR specification, InformationSource represents the origin of the information provided. For example, if a doctor records that a patient is taking a medication as reported by the patient, the InformationSource should be the patient, while the doctor remains the Recorder. Including InformationSource may not be necessary in this context. However, if it is used, its meaning must align with international standards to avoid semantic confusion and ensure proper data interoperability.
Remarks for 1.4.1 Product/Substance:
Could you clarify the rationale for using SnomedCT instead of VMPGroup (VOS)? Using VMPGroup seems logical given the structure and coding of medications in Belgium. A clarification of this choice would be helpful.
Remarks for 1.4.1 ReasonReference:
The use of Reason as the FHIR item needs clarification. Reason refers to why a medication is being taken. In the international standard, this is typically a CodeableReference to a Condition, Procedure, or similar entity. Is it necessary to include this if a CarePlan already links to a Problem? A clearer justification for including Reason here would be helpful.
Remarks for 1.4.1 DosageInstruction:
This needs to be elaborated extensively with examples and guidelines for various dosage regimens (e.g., simple dosages, tapering schedules). The current definition is too broad within FHIR, and without clear examples, there is a risk that everyone will implement this differently, which is the same issue we have encountered with Kmehr. Detailed guidelines are essential to ensure uniformity in use.
SAM2 Definitions: SAM2 has now created its own definitions for dosage forms. These need to be fully adapted to align with the FHIR standard.
Remarks for 1.4.1 OverrideReason:
Please align with SAM2. It is currently configured to display a warning only if the prescriber exceeds 3x or 2x the regular dose. Additionally, not all dosages are included in SAM2, only around 80%. What happens if no dosages are given for the requested conditions? Also, conditions cannot be checked against SAM2 as they are not coded—how should we handle this scenario?
Remarks for 1.4.1 Note:
In FHIR, Note is intended to provide additional information about usage. It does not seem to be a specific note meant for healthcare providers. Could you clarify the intended scope of this field?
Remarks for 1.4.1 PSSReason:
Could you clarify the role of PSS? Why is SAM2 referenced earlier and PSS here? Will there be two systems for determining dosage? This seems potentially very confusing for physicians. Please clarify the rationale to ensure alignment and avoid confusion.
Remarks for 1.4.2 MedicationType:
How do we want to register VOS in MedicationType?
Remarks for 1.4.2 VisiFlag:
VisiFlag is also removed; please refer to the earlier comment.
Remarks for 1.5.2 MedicationLine:
What is the cardinality of MedicationLine? Is it mandatory or not?
Remarks for 1.5.2 Version:
Same as on 1.4.2; could you explain why versioning is handled differently here?
Remarks for 1.5.2 StatusReason:
StatusReason seems irrelevant here. It appears to be more of an administrative burden.
Remarks for 1.5.2 Substance:
Are we using VMPGroup for VOS?
Remarks for 1.5.2 Organization:
FHIR Type: InformationSource
InformationSource represents the entity providing the information. If we consider a workflow where a nursing home requests a prescription, it seems reasonable that this could be represented as InformationSource if the doctor prescribes it. What is the use case here?
Remarks for 1.5.2 ReasonReference:
Why duplicate information? There is already a CarePlan, a Problem, and a MedicationStatement in place to capture the reason. As I understand it, MedicationRequest cannot exist without an associated MedicationStatement.
Remarks for 1.5.2 DosageInstruction:
Same remark as on 1.4.2 DosageInstruction regarding the need for elaboration and guidelines for various dosage regimens.
Remarks for 1.5.2 SubstitutionAllowed:
Is SubstitutionAllowed mandatory, or should it only be indicated if substitution is not allowed? This would reduce redundancy for healthcare providers.
Remarks for 1.5.2 InstructionForReimbursment:
FHIR Type: ClaimResponse? Using ClaimResponse appears to be excessive for this purpose. Could a smaller, more targeted resource be more suitable?
Remarks for 1.5.2 Note:
Same remark as on 1.4.2 Note regarding its intended purpose.
Remarks for 1.5.2 DispenseRequest:
What is the cardinality of DispenseRequest? Is it mandatory or not?
Remarks for 1.5.2 DispenseInterval:
Could you provide some use cases to demonstrate how DispenseInterval is used?
Remarks for 1.5.2 QuantityPerDispense:
Could you provide some use cases to demonstrate how QuantityPerDispense is used?
Remarks for 1.5.3:
Is there a reason for excluding the entered-in-error status? The meaning of this is that for some reason, it should not have been recorded at all. What is the approach here?

[costateixeira]

Remarks for 1.4.1 Version:

• we suggest to use the identifier.period and remove versionIdentifier

Remarks for 1.4.1 Recorder:

• we need to change this to really mean "recorder". Since MedicationStatement does not have such an element, we will create a custom extension (after double-checking with the international community).

Remarks for 1.4.1 Product/Substance:

• we don't prescribe terminologies in the profile just yet (we may when they are provided by terminologist). We do however recommend changing the document to add VMP Group to the list of target terminologies.
  suggest add to the document a consideration that sometimes the product is not coded (e.g. magistral) or not in the existing valuesets (e.g. foreign products) : ", sauf pour les cas où l’information n’es pas structurée ou codée – p.ex. préparations magistrales."
• we will also rename medicinalproduct.identifier to .code (CodeableConcept, to allow also free text)

Remarks for 1.4.1 ReasonReference:

• we agree to keep it, but will add rationale (which is: 1. this is so common that we do want to make it central when it exists and 2. if we use this only through CarePlan, then careplan becomes mandatory for adding an indication. which is not ideal).

Remarks for 1.4.1 DosageInstruction:

• we agree that will provide some examples. we will investigate the discrepancies between SAMv2 and FHIR. Corilus to propose a new issue for creating dosage examples.

[costateixeira]

Remarks for 1.4.1 DosageOverrideReason:

• if the prescription is for e.g. 2-3 times the recommended dosage, there should be a warning
• what if there is no dosage stated in the prescription - this can happen e.g. for creams, ointments, etc.
• what if the dosage is not structured?
  We agree that the DosageOverrideReason is optional and it can be defined by the physician in different circumstances. It may be driven by SAMv2 but that may not always be the case - in case of unstructured dosages, or some medications. For this reason, we will not add any logic in the profile for determining when the DosageOverrideReason must be filled in. We can provide this rationale in the guidance.

Remarks for 1.4.1 Note:
RIZIV will change the document to read "Texte libre avec informations additionnelles sur la ligne de médication". instead of the "prestataire de soins"

Remarks for PSS Number and PSS Reason:

• The PSS Number+Reason are separate from the dosage Override. We will clarify the separation in the data elements:
• PSS Number indicates what was the PSS ID that triggered the creation of the MedicationLine, if any. PSS Reason contains the prescriber's justification for deviating from that PSS ID, if applicable. This is different from the DosageOverrideReason which is only about the dosage. In ohter words, PSS Number and Reason is about whether a medication has been proposed by the PSS system and we need to keep track of that advice- PSS Reason is not only about the dosage; DosageOverride(Reason) is independent of PSS or not, and whether the dosage differs from the SAMv2 recommendations.
  All of this will be commented out in the first version of the MedicationLine.

Remarks on Medication/MedicationType - how to use VOS:

• VOS is the granularity of the medication. So it will be in the code systems of the Medication element. It is not a medicationType

Visiflag to be removed.