Degraded medications
Where degraded medication records arising from GP2GP record transfer or any other means are present in the patient record then these MUST be coded using the appropriate degrade code (196421000000109, Transfer-degraded medication entry) with the original medication name conveyed by CodeableConcept.text.
Medication interoperability
Consumers of medication resources generated by other systems MUST consider the clinical safety issues arising from processing medication information recorded in different care settings and contexts, and seek clinical safety guidance where appropriate.
Key concerns are the understandability of received medication information and appropriate actions to degrade and identify medication concepts which are not understood by the receiving system. Appropriate clinical workflows may also be required at the receiver - for example, deactivation of received medications such that they MUST be explicitly re-authorised to make them issuable.
Currently dosage and quantity information are expressed in unstructured/textual form. A system intending to consume dosage and quantity information needs to be capable of handling unstructured quantities and dosages.
Mixtures
In some systems it is possible to prescribe custom formulations compounded from other medications (extemporaneous preparations). Mixtures MUST be expressed using the degrade code (196421000000109, Transfer-degraded medication entry) with the constituents of the mixture expressed via CodeableConcept.text.
dm+d name versus displayed name
It is possible for historic/legacy medications to be displayed with a name corresponding to the name in the original system’s drug dictionary rather than the dm+d name. This name SHOULD be preserved via CodeableConcept.text when representing the medication via resources. CodeableConcept.text is redundant when the displayed medication name on the original system and the dm+d name is identical, and, in these cases, CodeableConcept.text SHOULD be omitted.
Medication reviews
The resources required to describe diarised review activities and reminders for medication reviews are out of scope for this guidance.
Future-dated prescriptions
Medication issues may be future-dated – for example, repeat dispensed medications or a deferred acute medication that may not be needed if the condition resolves.
Amendments
Where an authorisation is amended – for example, Proprietary/Generic switch, altered dates, change of quantities and so on, then the existing authorisation/plan SHOULD be stopped or discontinued, and an appropriate reason supplied via statusReason.reason. A new authorisation SHOULD be created, in the form of a MedicationStatement and MedicationRequest with intent of plan, to hold the amended details. Subsequent issues of the medication SHOULD reference the amended authorisation rather than the previous version.
Medication discontinuation/stopping
Where a medication is stopped or discontinued then the status of the authorisation SHOULD be changed to ‘stopped’ and a textual stop reason provided via statusReason.reason.
A statusReason SHOULD NOT be generated when an authorisation has simply expired (exceeded review date or number of issues).
Authorisation
In conjunction with MedicationStatement, a MedicationRequest with an intent of plan represents an authorisation for acute, repeat, repeat dispensed medication.
Re-authorisation
Where a medication is re-authorised a new authorisation SHOULD be generated in the form of a MedicationStatement and MedicationRequest with intent of plan. Subsequent issues of the medication SHOULD reference the new authorisation.
