Implementing a Medication Overview poses challenges that we cannot always normalize:
What dates and times are relevant for the start of treatment: date of prescription start? date of dispense?
When a prescription is written with a "generic" name, the dispense is an actual medication.
What are the dates for inclusion of treatments - 6 months? 12 months?
What are the criteria for including drugs - one-offs are included? OTCs (although it seems universal that OTCs are included)? Food supplements and special nutrition products?
Vaccines included?
Some of these decisions may be "hardcoded" in the treatment lines - e.g. in one country, the treatment start date is always the prescription date, in another the dispense date may change the treatment start date.
This is important NOT necessarily to make every rule computable and interpretable, but so that receiving system can be aware of the possibility of differences.
This may influence our profiles (just an idea) that some of the elements may be "flagged" for the possibilit of contextual differences.
These guidelines will be relevant for user interface AND for interoperability - when information is exchanged, not only the UIs will differ, but the medication list may include the "flavour" that it is generated in.
When your system has implemented medication overview, you might still get odd prescriptions created on the side, and there must be a way to include them in the overview and turn them into official medication overview lines if necessary.
Reimbursement rate can be different on prescription and dispensation. Is there reimbursement for the treatment line as well, probably not? (it's down to local implementation I guess, but maybe we want to think about it)
Constructing a medication overview. The current overview includes ongoing and future treatments. A medication overview in a point in time in history should include only treatments that were ongoing at that time: both, treatment lines and actual dispensations should be taken into account and UI should convey that information.
Decision support warnings are probably not the part of medication overview, but calculated on spot. However, there might be a need to store which interactions where known to a doctor at the time of prescribing. Where will that information go?
Implementing a Medication Overview poses challenges that we cannot always normalize:
Some of these decisions may be "hardcoded" in the treatment lines - e.g. in one country, the treatment start date is always the prescription date, in another the dispense date may change the treatment start date. This is important NOT necessarily to make every rule computable and interpretable, but so that receiving system can be aware of the possibility of differences. This may influence our profiles (just an idea) that some of the elements may be "flagged" for the possibilit of contextual differences.
These guidelines will be relevant for user interface AND for interoperability - when information is exchanged, not only the UIs will differ, but the medication list may include the "flavour" that it is generated in.