GP Connect - Update Record (ITK3)

Part of the GP Connect product family
A newer version of this specification is available (v1.1.1-public-beta).
An issue was identified with the FHIR package supplied with this version of the specification, which has been rectified.
Please click here to view the patched v1.1.1-public-beta specification with the updated FHIR package.

How to handle updates to payloads

Note: In FHIR, the terminology to update a payload is known as a replacement.

The GP Connect Update Record capability allows for the updating of a previously sent payload.

This replacement is at a whole payload level, in that the original payload is replaced by a new one and the old payload is only kept for audit purposes.

A sender may choose to send a new replacement payload for several reasons, for example:

  • the original payload contained an error, identified after the payload was sent
  • the sender has more up-to-date or complete information - for example, the original is correct but further information is now available to make the payload more complete or detailed
  • receivers of updated versions of payloads MUST process the updated payload and archive the previous one

FHIR elements used for replacement

The elements in the resources below can be used to indicate that a replacement payload has been received:

  • Composition.meta.versionId
  • Composition.status
  • Composition.relatesTo.code
  • Composition.relateTo.targetIdentifier

Read more on how to populate these elements:

Replacement guidance

  • the relatesTo element within CareConnect-GPC-Composition-1 MUST be populated with the code of replaces and the targetIdentifier containing the ID of the payload it is replacing
  • the version SHOULD be included in the CareConnect-GPC-Composition-1 resource in meta.versionId
  • replacements MAY be done more than once, and the new document always refers to the previous document
  • multiple replacements SHOULD be avoided where possible due to complexity of maintaining the audit trail
  • replacement payloads SHOULD be sent within 24 hours of the original payload
  • the sender may wish to contact the receiving practice to notify them of the change

When the new payload cannot be processed

  • the receiver of the new payload SHOULD mark the original and replacement as null and void
  • an error SHOULD be reported to the sender using the ITK response message and appropriate code - see ITK3 response codes for more information
  • the sender of the new payload SHOULD mark the original and replacement payload as null and void if it receives an ITK3 response indicating that the replacement could not be processed
back to top