ePMA Implementation Guidance for FHIR STU3

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.
Please note: This guidance has been superseded by the Implementation guide for digitial medicines, which contains up-to-date information.

Query for 'Current' Medication

Most medicines use cases require the clinician to obtain a picture of the patient's current medication. Today, the patient's GP record is the most complete record of current medication. This data is made available in four ways;

  1. Directly by the clinical staff within the patient's GP practice
  2. In summary form uploaded [in England] to the NHS Summary Care Record
  3. Via the IM1 pairing integration
  4. Via the GPConnect API.

The strategic direction for medicines interoperability is the implementation of regional Integrated Care Systems (ICS) and/or Shared Medication Records. It is expected that every ICS or Shared Medication Record integrates with GPConnect to obtain the GP record of current medication, combining that data with other medicines data coming from other provider systems.

Where a region does not yet have an ICS or Shared Medication Record that integrates with GPConnect data, consuming systems can query GPConnect directly to retreive the GP's view of 'current' medication.

The consuming system wanting a view of 'current' medication should query the regional Integrated Care System (ICS) or Shared Medication Record to pull back the patient's current medication. This could be returned as a FHIR List or FHIR Bundle of MedicationStatement resources. It would also be valid to return the transactional FHIR resources of MedicationRequest and MedicationDispense. See implementation options below.


use-case-prescribing-system-querying-ics


Applicable FHIR resources: MedicationStatement, and optionally MedicationRequest and MedicationDispense

Definition of 'Current' Medication

IMPORTANT: A definition of what is deemed 'current' has been a challenge for healthcare IT for many years. This implementation guidance only provides a suggested approach. Until a national standard a published, accepted and proven, this guidance is of experimental status.

Suggested Criteria:

  • Medication where MedicationStatement.effectiveDateTime or MedicationStatement.effectivePeriod.start is in the past 12 months.
  • Medication prescribed where MedicationRequest.authoredOn is in the past 12 months and the intent is order.
  • Medication supplied/dispensed where MedicationDispense.whenPrepared or MedicationDispense.whenHandedOver is in the past 12 months.
  • Resources where status is active or complete.
NOTE: A period of 12 months is suggested in this guidance for the age of medication records deemed to be 'current'. Existing implementations across different types of clinical system are known to be using different algorithms, such as 6, 9 or 12 months.

Implementation Options

Option: Where is 'current' determined?

There are three architectural options for where 'current' medication is determined:

  1. By the ICS / shared record via an end-point to return only current medication
  2. By the consuming system, first by querying for a subset of medication records from the ICS / shared record, then applying further logic to determine what is 'current'
  3. By the consuming system, querying for all medication records, then applying further logic to determine what is 'current'.

For option 1, a query to an end-point to return only current medication for a given patient may look like this;

GET [base]/currentmedication?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|{NHS_Number}

For example;

GET https://myfhirserver.net/currentmedication?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|123543254
NOTE: Technically the above is not as per the FHIR standard as there is no 'currentmedication' operation defined within FHIR.

For Options 2 and 3, the FHIR standard includes various ways to search for resources. The following search parameters for these resources defined within the FHIR standard could be useful when querying for current medication.

MedicationStatement

  • subject[patient].identifier
  • status (where active or complete)
  • effective (will pick up either effectiveDateTime or effectivePeriod)

For example;

GET [base]/MedicationStatement?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|123543254&status=active,complete&effective=ge2020-05-11

MedicationRequest

  • subject[patient].identifier
  • status (where active or complete)
  • intent (where order)
  • authoredOn

For example;

GET [base]/MedicationRequest?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|123543254&status=active,complete&intent=order&authoredOn=ge2020-05-11

MedicationDispense

  • subject[patient].identifier
  • status (where active or complete)
  • whenPrepared

For example;

GET [base]/MedicationDispense?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|123543254&status=active,complete&whenPrepared=ge2020-05-11

Option: What type FHIR resources are returned?

There are four architectural options for which FHIR resources are returned:

  1. Only MedicationStatement resources
  2. Only MedicationStatement resources but including basedOn referenced MedicationRequest resources for prescribed medication
  3. A combination of MedicationRequest for prescribed medication with MedicationStatement resources for non-prescription supply
  4. A combination of MedicationRequest for prescribed medication, MedicationStatement resources for non-prescription supply and MedicationDispense resources.

The decision for which resources to return will primarily be dictated by the level of data required by consumer systems. The MedicationStatement resource can summarise data contained within MedicationRequest and MedicationDispense resources. For many use cases, the level of detail available within a MedicationStatement resource will be sufficient.

It would be feasible to build an initial implementation of the query for current medication to return only MedicationStatement resources. This can be extended in a future build to return the more detailed resources if/when these are required to support additional and more complex consumer use cases.

back to top