GP Connect - Update Record (ITK3)

Part of the GP Connect product family

Rejecting messages

This section aims to articulate the reasons as to why messages may be rejected by the consuming (receiving) system.

Unsupported FHIR profiles being sent

Important: The entire ITK3 message will be rejected if unsupported profiles are sent.

This is because ITK3 does not lend itself to chatty acknowledgements to articulate to the sending system that only part of the information has been accepted and the rest has rejected.

This could introduce clinical risk.

It is safer for the receiver to reject the entire message, with the ITK3 rejection code: 20009 (Payload content validation has failed).

ITK3 Response Codes (2.10.0-live)

Understanding intent

Although FHIR allows caters to a certain extent in being able to provide context around the intent, it does not always make it clear to the receiver what the intent from the sender was.

Using allergies as an example.

  • a pharmacist may ask a patient whether they have any allergies
  • the patient states they are allergic to tree and grass pollen (hayfever)
  • the pharmacist records this onto their clinical system
  • the pharmacist may decide to relay that information onto the GP system

Once the GP receives this information, they need to perform the following options:

  • validate that the contents of the FHIR payload is valid
  • interrogate their internal patient record and pull out the list of allergies

The GP system now needs to apply some sort of business logic to determine the following:

  • Is the allergy already known?
  • If it is - should it be updated?
  • If it isn't - does the GP 'trust' the sender well enough to add it to the patient record?
  • Should it be added as unverified?

Even if that was worked out, there are additional edges cases that need to be thought about:

  • What if the sender makes a mistake and sends an update to say that allergy was incorrect and needs to be removed?
  • What if the GP has acted on the first message and arranged an appointment with the patient to discuss their allergy in greater detail?
These scenarios need to be fully understood, and clinically-led guidance needs to be created so that receivers know what to do with these type of updates - not just for allergies, but other types of information too.

Other reasons for rejection

The following are examples of where a message may be rejected by the receiving system.

The patient may not be known by the practice The message could have been routed to the wrong GP practice.
The patient may have recently moved GP practices, or are part way through transferring The message may have been sent to the old practice, rather than the new one that the patient is now registered at.
The GP may decide to reject the message upon review as they do not want it in their patient record It's not understood the reasons why a message may be rejected; however, since a task in workflow is being created to 'accept' the incoming message, it is possible that a GP practice could reject it - intentionally, or otherwise. It is advised that in such circumstances, the receiving practice should notify the sending organisation that they have rejected the payload.
back to top