Introduction
Links to the definitions of the MedicationRequest resource within the specifications covered within this guidance.
- MedicationDispense resource within STU3
- MedicationDispense resource within CareConnect
- MedicationDispense resource within R4
Minimum Viable Product (MVP)
Elements marked as MVP denote those recommended to be required for an MVP for the target use case.
Elements across FHIR Versions
Element | MVP | STU3 | CareConnect | R4 |
---|---|---|---|---|
id |
MVP | ✔ | ✔ | ✔ |
identifier |
MVP | ✔ | ✔ | ✔ |
partOf |
✔ | ✔ | ✔ | |
status |
MVP | ✔ | ✔ | ✔ |
statusReason[x] |
? | ✖ | ✖ | ✔ |
category |
MVP | ✔ | ✔ | ✔ |
medication[x] |
MVP | ✔ | ✖ | ✔ |
medicationReference |
MVP | ✖ | ✔ | ✖ |
subject |
MVP | ✔ | ✔ | ✔ |
context |
✔ | ✔ | ✔ | |
supportingInformation |
? | ✔ | ✔ | ✔ |
performer |
MVP | ✔ | ✔ | ✔ |
location |
✖ | ✖ | ✔ | |
authorizingPrescription |
MVP | ✔ | ✔ | ✔ |
type |
✔ | ✔ | ✔ | |
quantity |
MVP | ✔ | ✔ | ✔ |
daysSupply |
MVP | ✔ | ✔ | ✔ |
whenPrepared |
MVP | ✔ | ✔ | ✔ |
whenHandedOver |
✔ | ✔ | ✔ | |
destination |
MVP | ✔ | ✔ | ✔ |
receiver |
✔ | ✔ | ✔ | |
note |
MVP | ✔ | ✔ | ✔ |
dosageInstruction |
MVP | ✔ | ✔ | ✔ |
substitution |
MVP | ✔ | ✔ | ✔ |
detectedIssue |
✔ | ✔ | ✔ | |
notDone |
✔ | ✔ | ✔ | |
notDoneReason[x] |
✔ | ✔ | ✔ | |
eventHistory |
✔ | ✔ | ✔ | |
meta |
✔ | ✔ | ✔ | |
implicitRules |
✔ | ✔ | ✔ | |
language |
✔ | ✔ | ✔ | |
text |
✔ | ✔ | ✔ | |
contained |
✔ | ✔ | ✔ | |
modifierExtension |
✔ | ✔ | ✔ |
Medication Dispense Elements
id
Date Type: | Id |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The logical internal id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
identifier
Date Type: | Identifier |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
External IDs for this request. Identifiers associated with this medication request that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. They are business identifiers assigned to this resource by the performer or other systems and remain constant as the resource is updated and propagates from server to server.
partOf
Date Type: | Reference(Procedure | CareConnect-Procedure-1) |
Required / Cardinality | Optional 0..* |
Version Support | STU3 , CareConnect , R4 |
The procedure that the dispense is done because of.
It is recommended this element is not implemented as part of an MVP.
status
Date Type: | Code |
Required / Cardinality | Required (STU3/CareConnect) 0..1 , Mandatory (R4) 1..1 |
Version Support | STU3 / CareConnect , R4 |
The cardinality of status has been changed from 0..1 in STU3 to 1..1 in R4.
When used it must be populated with a fixed value set defined within the FHIR standard.
It is expected that most implementations will require the use of status to support workflow.
Note The value sets between STU3/CareConnect
and R4
differ, and an example workflow and interpretation of these statuses is yet to be defined.
statusReason[x]
Date Type: | CodeableConcept | Reference(DetectedIssue) |
Required / Cardinality | Required 0..1 |
Version Support | R4 |
This could be used; however, it is only compatible with R4.
At this time, it is unknown as to whether this should be included as part of the MVP.
category
Date Type: | CodeableConcept |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
Indicates the type of medication dispense (for example, where the medication is expected to be consumed or administered (i.e. inpatient or outpatient)).
medication[x] for STU3 and R4, medicationReference for CareConnect
Date Type: | CodeableConcept | Reference(Medication) |
Required / Cardinality | Mandatory 1..1 |
Version Support | STU3 / CareConnect , R4 |
Where the requested medication is contained within the NHS dm+d then it must be recorded using the dm+d standard. Implementation is recommended to be via a referenced Medication resource.
See the Overview page for guidance on using FHIR References.
Note: At the time of writing an alpha implementation of a dm+d FHIR Medication Resource Server is available from the North East CSU as a demonstrator and associated API.
It is recommended that the medicationReference.display
is populated with the medication description as selected by the clinician. This may be slightly different to the medication described as returned by a SNOMED/dm+d terminology FHIR server if the ePMA system has not fully implemented dm+d into their medication picking list.
Requested medication with no dm+d code
Medication not published within the dm+d may be requested in the Acute care setting. In this scenario it is recommended to use the CodeableConcept variant for this element. Software logic can then clearly distinguish this from nationally coded dm+d medication.
If the ePMA system has both a locally assigned code and description for the medication then;
- The
medicationCodeableConcept.text
should be the description for the medication. - The
medicationCodeableConcept.coding.code
should be the code for the medication. - The
medicationCodeableConcept.coding.display
should be the description for the medication, i.e. the same value asmedicationCodeableConcept.text
.
If the ePMA system only has a description for the medication then;
- The
medicationCodeableConcept.text
should be the locally assigned description for the medication.
subject
Date Type: | Reference(Patient | Group | CareConnect-Patient-1 ) |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
See the Overview page for guidance on using FHIR References.
Note: It is acknowledged that a typical Hospital Patient Administration System (PAS) available today will not expose a FHIR interface so referencing by URL will most likely not be available for some time. However this should be a target architecture so that the FHIR-enabled PAS can be used as a trusted source of Patient resources across multiple hospital systems.
See population of a Patient resource.
context
Date Type: | Reference(Encounter | EpisodeOfCare | CareConnect-EpisodeOfCare-1) |
Required / Cardinality | Required 0..1 , |
Version Support | STU3 / CareConnect , R4 |
The encounter or episode of care that establishes the context for this event.
It is recommended this element is not implemented as part of an MVP.
supportingInformation
Date Type: | Reference(Any | Resource) |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
Additional information that supports the medication being dispensed.
At this time, it is unknown as to whether this should be included as part of the MVP.
Note This can link to any FHIR resource - could this be used for financial information (e.g. cost centres)?
performer
Date Type: | BackboneElement |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
Indicates who performed the event - e.g. the person the dispensed the medication. It’s likely that the recipient will want to know this information,
This is most likely going to be a UK Core Practitioner Role (GPhC registration) as Organisation on its own is not specific enough.
location
Date Type: | BackboneElement |
Required / Cardinality | Optional 0..* |
Version Support | R4 |
The principal physical location where the dispense was performed.
For primary care this will likely be business required; however, is this needed for secondary care?
It is recommended this element is not implemented as part of an MVP.
authorizingPrescription
Date Type: | Reference(MedicationRequest | CareConnect-MedicationRequest-1 ) |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
A reference to the original medication request.
FHIR guidance states optional; however, this should be mandatory for any implementation within England.
Refer to the medicationRequest implementation guidance for more information.
type
Date Type: | CodeableConcept |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
Indicates the type of dispensing event that is performed. For example, Trial Fill, Completion of Trial, Partial Fill, Emergency Fill, Samples, etc.
This will most likely be a type of prescription-dispensing
- could it be used for anything else?
It is recommended this element is not implemented as part of an MVP.
quantity
Date Type: | SimpleQuantity |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The amount of medication that has been dispensed. Includes unit of measure.
Prefer both product and dose based quantity should be included for readability.
For example: insert example here
daysSupply
Date Type: | SimpleQuantity |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The amount of medication expressed as a timing amount.
This could be tricky as may not always be able to provided - e.g. “use when required” indicates that usage is optional, and may not be able to be calculated.
whenPrepared
Date Type: | dateTime |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The time when the dispensed product was packaged and reviewed.
whenHandedOver
Date Type: | dateTime |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The time the dispensed product was provided to the patient or their representative.
This could be a useful component to capture; however, it is recommended this element is not implemented as part of an MVP.
destination
Date Type: | Reference(Location | CareConnect-Location-1) |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The principal physical location where the dispense was performed.
It is assumed that this will be useful, hence suggested in the MVP; however, what would it be used for?
receiver
Date Type: | Reference(Patient | Practitioner | CareConnect-Patient-1 | CareConnect-Practitioner-1) |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
Identifies the person who picked up the medication. This will usually be a patient or their caregiver, but some cases exist where it can be a healthcare professional.
It is recommended this element is not implemented as part of an MVP.
note
Date Type: | Annotation |
Required / Cardinality | Required 0..* |
Version Support | STU3 / CareConnect , R4 |
Extra information about the dispense that could not be conveyed in the other attributes.
dosageInstruction
Date Type: | Dosage |
Required / Cardinality | Required 0..* |
Version Support | STU3 / CareConnect , R4 |
A required business element for all MVP implementations.
Population of just the dosageInstruction.text
element would be unacceptable for a successful implementation.
Refer to FHIR Dose Syntax Implementation Guidance (or any subsequent version) for guidance.
substitution
Date Type: | BackboneElement |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
Indicates whether or not substitution was made as part of the dispense. In some cases, substitution will be expected but does not happen, in other cases substitution is not expected but does happen. This block explains what substitution did or did not happen and why. If nothing is specified, substitution was not done.
detectedIssue
Date Type: | Reference(DetectedIssue) |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
Indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient; e.g. drug-drug interaction, duplicate therapy, dosage alert etc.
It is recommended this element is not implemented as part of an MVP.
notDone
Date Type: | boolean |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect |
The default value of a boolean is false
.
Set to true
if the dispense was not performed for some reason.
It is recommended this element is not implemented as part of an MVP.
notDoneReason[x]
Date Type: | CodeableConcept | Reference(DetectedIssue) |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect |
Indicates the reason why a dispense was not performed.
It is recommended this element is not implemented as part of an MVP.
eventHistory
Date Type: | Reference(Provenance) |
Required / Cardinality | Optional 0..* |
Version Support | STU3 / CareConnect , R4 |
A summary of the events of interest that have occurred, such as when the dispense was verified.
It is recommended this element is not implemented as part of an MVP.
meta
Date Type: | Meta |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content may not always be associated with version changes to the resource.
It is recommended this element is not implemented as part of an MVP.
implicitRules
Date Type: | Uri |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content.
It is recommended this element is not implemented as part of an MVP.
language
Date Type: | Code |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
The base language in which the resource is written.
It is recommended this element is not implemented as part of an MVP.
text
Date Type: | Narrative |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
A human-readable narrative that contains a summary of the resource, and may be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it “clinically safe” for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
It is recommended this element is not implemented as part of an MVP.
contained
Date Type: | Resource |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope.
It is recommended this element is not implemented as part of an MVP.
modifierExtension
Date Type: | Extension |
Required / Cardinality | Required 0..1 |
Version Support | STU3 / CareConnect , R4 |
May be used to represent additional information that is not part of the basic definition of the resource, and that modifies the understanding of the element that contains it. Usually modifier elements provide negation or qualification. In order to make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions.
Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.
It is recommended this element is not implemented as part of an MVP.