Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Medication guidance

Guidance on the representation of medication in GP Connect

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.


All content is available under the Open Government Licence v3.0, except where otherwise stated