A Sender needs to be aware of a number of constraints associated with sending documents, generally considered in two categories, payload constraints and a patients' consent and preferences.

ITK3 Number of Payloads Constraint

ID Description Sender Receiver
FHIR-PAY-01 A sending system MUST only send one document per transmission. Y N
ID Description Sender Receiver
FHIR-PAY-02 Attachments MUST be included within the same FHIR Bundle. Y N
NB There will not be any external references via URL.

It is essential that the identity of the patient is consistently represented by systems that are interacting with one another and that a patients’ preferences are recognised.

PDS Connected Systems

Where sending systems are connected to PDS, full PDS Synchronisation will be carried out prior to any messaging interaction and therefore the locally held serial change number will be up-to-date. If the sending system is not connected directly to PDS and synchronises with PDS periodically, e.g. using the PDS Batch service, the latest details should be sent.

ID Description Sender Receiver
FHIR-PDS-01 Sending systems SHOULD synchronise the document with the PDS record. Y N
ID Description Sender Receiver
FHIR-PDS-02 The Sender MUST include additional patient demographics if the patient’s NHS number is not included or the NHS number has not been "verified". Y N
1. The Sender MUST include additional patient demographics if the patient’s NHS number is not 'verified':
  • First Given Name
  • Surname
  • Gender
  • Date of Birth
  • Address
  • Postcode
ID Description Sender Receiver
FHIR-PDS-03 If the Sender is connected to PDS, prior to sending a document, the originating system SHOULD check the PDS ‘flagged’ status of the Patient’s record. Y N
ID Description Sender Receiver
FHIR-PDS-04 Where a record is marked as 'S' (Sensitive) on the PDS, following an appropriate safety evaluation (by the local user organisation as data controller) the Sender MAY include Patient address or contact details in the additional demographic data, these items are (PDS data items):
  • Addresses
  • Telecom Addresses
  • Patient Care (All types)
  • Alternative Contacts
 Y N
ID Description Sender Receiver
FHIR-PDS-05 Where an NHS number is known to be invalid on PDS (error code '22' upon a PDS Retrieval), the Document SHOULD NOT be sent until the issue has been resolved. Y N
ID Description Sender Receiver
FHIR-PDS-06 Where an NHS number is known to be invalid on the PDS (error code '22' upon a PDS Retrieval), documents MUST NOT contain the patient's NHS number. Y N
ID Description Sender Receiver
FHIR-PDS-07 Where an NHS number is known to be invalid on the PDS (error code '22' upon a PDS Retrieval), if the Document is sent (and this can only be done with ITK3 Message Specifications) other (non- NHS number) demographic details MUST be included.
  • First Given Name
  • Surname
  • Gender
  • Date of Birth
  • Address
  • Postcode
 Y N
ID Description Sender Receiver
FHIR-PDS-08 Where a record is marked as 'B' (formerly meaning 'Business Flagged' prior to 2008-B but now meaning 'Under Data Quality Investigation' from spine release 2008-B onwards) on PDS, documents MUST still be sent. Y N
ID Description Sender Receiver
FHIR-PDS-09 Where a Patient dissents from sharing their detailed care records and the document is a routine clinical communication, the originating system SHOULD still send documents for that Patient to the Patient’s GP Practice. Y N
ID Description Sender Receiver
FHIR-PDS-10 The verification status code (an NHS Extension) MUST be populated in the Patient Profile. Y N

Systems not connected to PDS

If the system is not connected to PDS at all then sufficient identifying attributes should be sent to enable a receiving system to match them to an existing record (if applicable) or create a new record (if applicable). Where possible the NHS number must be indicated.

ID Description Sender Receiver
FHIR-DEM-01 If the patient’s NHS number is not known the system MUST include an alternative local patient identifier in the text section. Y N
ID Description Sender Receiver
FHIR-DEM-02 If the patient’s NHS number is not known the system MUST include additional demographics. Y N
1 When a system ONLY sends a local patient identifier it MUST as a minimum also include:
  • First Given Name
  • Surname
  • Gender
  • Date of Birth
  • Address
  • Postcode

ITK3 Documents - Text Section Exclusions

ID Description Sender Receiver
FHIR-TXT-01 To avoid unnecessary and potentially disruptive duplication when a FHIR document is rendered, certain information SHOULD NOT be included in the text section of a FHIR document but SHOULD be carried in the FHIR resource specified within the document profile.
Below are examples of the type of information covered by this requirement.		 Y N
  • Document timestamp
  • Author of document
  • Recipient
  • Custodian
  • Encounter information
  • Care setting type

ITK3 FHIR Coded Entries

Where a Sending System has the functionality to support coded clinical entries for medications, FHIR documents created by that system should include coded entries where possible.

ID Description Sender Receiver
FHIR-CE-01 Where an originating system has the functionality to support coded clinical entries for medications, documents created by that system MUST include coded entries. Y N
1 If an originating system has the functionality to support SNOMED CT coded entries for medications, then documents generated by that system and which contain medication information MUST include SNOMED CT coded medication entries of dm+d.
2 Where an originating system does not have functionality to support coded clinical entries for medications, then documents created by that system MUST contain medication information as text
ID Description Sender Receiver
FHIR-CE-02 Where an originating system has the functionality to support coded clinical entries for allergies and drug sensitivities, documents created by that system SHOULD include coded entries where possible. Y N
1 If an originating system has the functionality to support SNOMED CT coded entries for allergies and drug sensitivities, then documents generated by that system and which contain allergies and drug sensitivities information MUST include SNOMED CT coded allergies and drug sensitivities entries.
2 Where an originating system does not have functionality to support coded clinical entries for allergies and drug sensitivities, then FHIR documents created by that system MUST contain allergies and drug sensitivities information as text.

Multiple Recipients

ID Description Sender Receiver
FHIR-MR-01 The contents of a document MUST be the same for every recipient. Y N
1 Having the same document for every recipient MUST be achieved by addressing an identical clinical payload (document) to each of the recipients.
2 The payload MUST be syntactically and semantically identical regardless of the number of receivers.

UUIDs and Version numbers

In generating documents, the sender Must meet the following requirement.

ID Description Sender Receiver
FHIR-VER-01 Systems creating new Documents MUST generate a unique document identifier. Y N

FHIR - General Sender Requirements

This section defines the general sender requirements, including the FHIR mandated elements that need to be populated.

ID Description Sender Receiver
FHIR-SR-01 FHIR Mandate - Where it is indicated that a document recipient is required to act on the contents of a FHIR document, the originating system MUST set:
MessageHeader.extension(ITKMessageHandling) – RecipientType = "FA"(For Action). 		Y N
ID Description Sender Receiver
FHIR-SR-02 FHIR Mandate - Where it is indicated that a document recipient is not required to act on the contents of a FHIR document, the originating system MUST set:
MessageHeader.extension(ITKMessageHandling) - RecipientType = "FI" (For Information). 		Y N
ID Description Sender Receiver
FHIR-SR-03 FHIR Mandate – To indicate the Sender Reference the originating system MUST set:
MessageHeader.extension(ITKMessageHandling) – SenderReference = <up to any 255 character string> (Default Value= None) 		Y N
ID Description Sender Receiver
ID Description Sender Receiver
FHIR-SR-05 FHIR Mandate – To indicate the Message Definition the originating system MUST set:
MessageHeader.extension(ITKMessageHandling) – MessageDefinition = <a URI>		 Y N
ID Description Sender Receiver
FHIR-SR-06 NHS Digital have provided a Local Extension key, that can be populated and defined to suit local requirements: -, the originating system MUST set:
MessageHeader.extension(ITKMessageHandling) – Local Extension = <is of any type>. (Default = String, Value= None) 		Y N
NB The default value of None means local extensions are not being used.
Tags: fhir