Implementation guide for interoperable medicines

This guidance is under active development by NHS England and content may be added or updated on a regular basis.

Interactions

This implementation guide covers a number of use cases, for which there may be various technical implementations using different types of interaction. Whilst the data shared within an interaction will be the same, e.g. the sharing of a MedicationRequest or MedicationStatement, the nature of the interaction may vary. Within one implementation a record may be shared via a RESTful GET operation. Within another, sharing the same FHIR resource(s) may be via a RESTful POST operation.

Depending on the chosen interoperability architecture, the use of specific FHIR data elements will change.

Use of identifier

The identifier is the most important element of a FHIR resource for interoperability. It acts as the externally facing unique business identifier for the resource. A key phrase from the FHIR R4 standard is;

[for identifier] ...All resources that have an identifier element support searching by the identifier, so that records can be located by that method.

Use of id

By contrast, the resource id is normally an internally facing unique logical identifier. Within the FHIR R4 standard is the key phrase related to the logical id where it is:

[for id] ...assigned by the server responsible for storing it

Where a nationally understood unique identifier exists for a resource then it could be feasible to use this as both the identifer and id. An example would be the unique code for an NHS organisation, where the ODS Code is an established national standard.

Use of status

The different types of business status for MedicationRequest and MedicationDispense resources made visible within systems may change depending the interoperability architecture.

Within some architectures, only valid end-states may be exposed, e.g. 'active' MedicationRequests. This would be the case when resources are POSTed to a FHIR server. The sharing of resources with a status such as 'draft' or 'entered-in-error' via a POST operation is illogical.

Within other architectures, when systems query the system acting as the FHIR server, records of any state may be returned. This may include resources with a status such as 'draft' or 'entered-in-error'.

Create

The adoption of a common POST API syntax would allow the same software to, for example, POST a FHIR resource point-to-point to a dispensing system, or a FHIR resource to a service like the Electronic Prescription Service (EPS), or a FHIR resource to a shared records service. A service like the EPS may require some additional data elements, but the mechanism of posting can be the same, using a different base URL technical end-point.

When POSTing a FHIR resource using a RESTful API use;

POST [base]/{resource}

For example;

POST https://myfhirserver.net/medicationrequest

with a body containing a single FHIR resource. Other resources referenced must be referenced with valid identifer values to allow the consumer system to locate those resources from either the same or another FHIR server.

{
    "resourceType": "MedicationRequest",
    "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
    // etc.
}

When POSTing a FHIR Message use;

POST [base]/$process-message

with a body containing a FHIR Bundle within which is a FHIR MessageHeader resource and multiple other FHIR resources.

{
  "resourceType": "Bundle",
  "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03083",
  "identifier": {
    "system": "https://tools.ietf.org/html/rfc4122",
    "value": "34470bbf-07cb-4b49-bef9-f958114f821f"
  },
  "type": "message",
  "entry": [
    {
      "fullUrl": "urn:uuid:0A1FD9EF-A3D5-4E95-84CD-552070A03083",
      "resource": {
        "resourceType": "MessageHeader",
        "id": "0A1FD9EF-A3D5-4E95-84CD-552070A03086",
        "eventCoding": { }, // etc.
        "sender": { }, // etc.
        "source": { }, // etc.
        "destination": { } // etc.
        }
    },
    {
      "fullUrl": "urn:uuid:a54219b8-f741-4c47-b662-e4f8dfa49ab6",
      "resource": {
        "resourceType": "MedicationRequest",
        "identifier": "a54219b8-f741-4c47-b662-e4f8dfa49ab6"
        // etc.
}

Read

Note: This section should, in time, be superseded by the UK Core Access API.

The adoption of a common GET API syntax to read a specific resource from a FHIR server would allow the same software to, for example, read a FHIR resource from a GP system or read a FHIR resource from shared records service. The query syntax can be the same, using a different base URL technical end-point.

GET by 'id'

To query a FHIR server for a specific resources where the id is a nationally understood unique identifier;

GET [base]/{resource}/{id}

Examples;

Where X26 is the ODS code as per the NHS Digital FHIR ODS API.

GET https://myfhirserver.net/Organization/X26

Where 9000000009 is a valid NHS Number as per the NHS Digital FHIR PDS API.

GET https://myfhirserver.net/Patient/9000000009

GET by 'identifier'

To query a FHIR server for a specific resource by identifier;

GET [base]/{resource}?identifier={value}

For example;

GET https://myfhirserver.net/MedicationRequest?identifier=a54219b8-f741-4c47-b662-e4f8dfa49ab6
back to top