StructureDefinition-UKCore-RequestGroup

Example Usage Scenarios

The following are example usage scenarios for the UK Core RequestGroup profile:

An example of the same drug, different route

This example shows how a request for the same drug through two different routes can be structured, with the decision to the more appropriate route being taken before a dispense is made.

• Example UKCore-MedicationRequest-ParacetamolIV
• Example UKCore-MedicationRequest-ParacetamolOral
• Example UKCore-RequestGroup-Paracetamol
• Example UKCore-MedicationDispense-ParacetamolOral
  
  
  

An example of different drugs, with a preference to one of them

This example shows how a request can be achieved giving the option for multiple different drugs, with one being preferred option and up to one being allowed to be dispensed.

• Example UKCore-MedicationRequest-Amoxicillin
• Example UKCore-MedicationRequest-Clarithromycin
• Example UKCore-MedicationRequest-Doxycycline
• Command 'pagelink' could not render: Page not found.
• Example UKCore-MedicationDispense-Amoxicillin
  
  
  

An example of same drug different doses, where both are dispensed but only one administered

This example shows a request of the same drug each with a different dose and route. This request allows both to be dispensed, with one being administered now and the other that may be dispensed at a later date or disposed.

• Example UKCore-MedicationRequest-CiprofloxacinIV
• Example UKCore-MedicationRequest-CiprofloxacinOral
• Example UKCore-RequestGroup-Ciprofloxacin
• Example UKCore-MedicationDispense-CiprofloxacinIV
• Example UKCore-MedicationDispense-CiprofloxacinOral
• Example UKCore-MedicationAdministration-CiprofloxacinIV
  
  

Profile Specific Implementation Guidance:

Minimum Viable Content

A minimum viable content that all provider and consumer systems SHALL support are the following elements.

intent

For any medication requests RequestGroup.intent SHALL have the value order. Each MedicationRequest referenced within the RequestGroup MedicationRequest.intent SHALL have the value option.

priority

When RequestGroup is used for medication requests the recommendation is that RequestGroup.priority is not to be used within an implementation - or used with caution.

The stating of a priority, in any business context including healthcare, is often de-valued as given the choice, every clinician wants medication urgently for their patients.

If RequestGroup.priority is used, consider only initially supporting the routine and urgent request priorities, and set clear criteria for when a MedicationRequest and RequestGroup should be marked and handled as urgent.

Usage of the value "stat"

The stat request priority is potentially confusing as it has two meanings:

1. to indicate a "here and now" order going to pharmacy
2. used within a MedicationRequest.dosageInstruction can also mean "give once immediately".

Avoid using stat and asap where possible.

subject

The resource being referenced SHALL conform to one of the following:

• Profile UKCore-Patient
• Group Resource

author

The resource being referenced SHALL conform to one of the following:

• Profile UKCore-Device
• Profile UKCore-Practitioner
• Profile UKCore-PractitionerRole

reasonReference

The resource being referenced SHALL conform to one of the following:

• Profile UKCore-Condition
• Profile UKCore-DiagnosticReport
• Profile UKCore-DocumentReference
• Profile UKCore-Observation

action

With the base FHIR constraint rule "Must have resource or action but not both" it is expected that:

• RequestGroup.action has multiple action elements, each defining an individual MedicationRequest.
• Within each of the Medication.action.action the resource element SHOULD reference the associated MedicationRequest.

action.participant

The resource being referenced SHALL conform to one of the following:

• Profile UKCore-Device
• Profile UKCore-Patient
• Profile UKCore-Practitioner
• Profile UKCore-PractitionerRole
• Profile UKCore-RelatedPerson