Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Requirements list

All requirements associated with Send Document.

List of all requirements

The following table contains all the requirements associated with the Send Document capability. Each row contains a link to requirement within the specification and the requirement description for a quick reference:

Link Requirement description
GPCM-C-01 MESH MUST be used as the message transport mechanism
GPCM-C-02 all FHIR Messages MUST conform to the ITK3 Message Distribution Standard, v2.5.0
GPCM-SD-103 the ITK3 MessageHeader.focus element MUST be a reference to a Bundle resource which conforms to the ITK-Document-Bundle profile
GPCM-SD-104 the ITK-Document-Bundle MUST contain a Composition resource profiled to CareConnect-Composition-1 base resource
GPCM-SD-105 the CareConnect-Composition Composition.custodian element MUST contain an Organization resource which conforms to the CareConnect-Organization-1 profile describing the organisation which sends the message
GPCM-SD-106 where the message contains patient information, for example as a result of a healthcare event, the CareConnect-Composition Composition.subject element MUST contain a patient resource which conforms to the CareConnect-Patient-1 profile
GPCM-SD-107 where the message contains practitioner information, for example as a result of a healthcare event, the CareConnect-Composition Composition.author element MUST be present which conforms to the CareConnect-Practitioner-1 profile. This resource describes the primary practitioner who delivered care.
GPCM-SD-108 all Meta elements MUST be treated as mandatory and populated with the associated resource
GPCM-SD-109 each binary document sent in the payload MUST be included as an instance of the Composition.section element
GPCM-SD-110 each Composition.section.entry MUST be a FHIR Reference containing a reference to an attachment profiled to ITK-Attachment-Binary-1
GPCM-SD-111 all attachments MUST be Base64 encoded
GPCM-SD-112 the primary attachment MUST be the first Composition.section.entry in the payload
GPCM-SD-113 a Composition resource profiled to CareConnect-Composition-1 resource MUST be present in the payload
GPCM-SD-114 Composition.status MUST contain fixed value final
GPCM-SD-115 Composition.type MUST contain the SNOMED code 371531000 (Report of clinical encounter)
GPCM-SD-116 Composition.date MUST contain the date/time the message was created
GPCM-SD-117 Composition.confidentiality MUST contain the fixed value N (Normal), or R (Restricted) if the consultation is classed as confidential
GPCM-SD-118 Composition.title MUST contain the fixed value Consultation report
GPCM-SD-119 Composition.text MUST contain a summary of request in the following format:
Consultation report for {Patient Name} , NHS Number {NHS Number}, seen at {Practice Name}*, ODS Code {ODS Code}*, Version {Version Number}
* these items MUST NOT be displayed if the consultation has been flagged as restricted/confidential
GPCM-SD-120 Composition.subject MUST contain a reference to Patient resource profiled to CareConnect-Patient-1
GPCM-SD-121 Composition.author MUST contain a reference to a practice Practitioner resource profiled to CareConnect-Practitioner-1
GPCM-SD-122 Composition.custodian MUST contain a reference to the sender practice Organization resource profiled to CareConnect-Organization-1
GPCM-SD-123 Composition.relatesTo MUST contain the UUID of the previous message if a replacement document is being sent
GPCM-SD-124 Composition.section.entry MUST reference a binary document which provides a report of the consultation in PDF format
GPCM-SD-125 where binary documents are included in the payload in addition to the Consultation Report, the message receiver MUST process these according ensuring all attachments remain in the context of the encounter information delivered to downstream systems
GPCM-SD-028 as described in Send Document - Payload structure, the payload MUST contain an organization resource describing the sender organisation (the originating practice)
GPCM-SD-029 the odsOrganisationCode slice of the identifier element MUST contain the ODS code
GPCM-SD-030 the name element MUST contain the name of the organisation
GPCM-SD-031 the telecom element MUST contain the telephone number of that organization. i.e. where telecom.system is set to a fixed value of phone, and telecom.value contains the telephone number
GPCM-SD-032 the SDS User ID of the practitioner MUST be present in the sdsUserID slice of the identifier element
GPCM-SD-033 the name of the practitioner MUST be present in the single instance of the name element where name.use is set to official
GPCM-SD-034 telephone contact details MUST be present if available in the Telecom element. i.e. telecom.system is set to a fixed value of phone, and telecom.value contains the telephone number
GPCM-SD-035 the NHS Number of the patient MUST be specified in the nhsNumber slice of the identifier element
GPCM-SD-036 the name of the patient MUST be present in the single instance of the name element where name.use is set to official
GPCM-SD-037 the date of birth of the patient MUST be specified in YYYY-MM-DD format in the birthDate element. Birth time is not required
GPCM-SD-038 values specified in the patient resource for surname, date of birth and NHS Number MUST match those specified in MESH metadata To_DTS field (for the MESH client) or Mex_To (for the MESH API) as described in MESH message configuration
GPCM-SD-039 RecipientType MUST be set to fixed value of FA ('For action') taken from FHIR ValueSet ITK-RecipientType-1

The meaning of RecipientType is applied in a common way across all ITK3 messaging. "For action" in this case indicates that the recipient is expected to take the action of attaching the payload contents to the patient record. ("For information" is analogous to an email "CC" where no action is expected from the recipient, and the message could be deleted.)

This item is found in the ITKMessageHandling extension within the ITK3 Message Header.
GPCM-SD-040 BusAckRequested MUST be set to fixed value of true. This will request an ITK3 Response with a response code in the range 30001 to 30003.

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-041 InfAckRequested MUST be set to fixed value of true. This will request an ITK3 Response with a response code in the range 10001 to 20013.

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-042 SenderReference MUST be set to the unique identifier of the encounter which has taken place at the sender practice.

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-043 MessageDefinition MUST be set to fixed value of https://fhir.nhs.uk/STU3/MessageDefinition/ITK-GPConnectSendDocument-MessageDefinition-1

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-044 LocalExtension MUST be set to fixed value of SendDocument-ConsultationReport

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-045 Sender MUST contain a reference to the CareConnect-ITK-Header-Organization-1 resource present in the FHIR message bundle
GPCM-SD-046 Source MUST contain the MESH mailbox ID of the sender
GPCM-SD-047 Event MUST contain a fixed value of ITK007C from code system ITK-MessageEvent-2
GPCM-SD-048 Timestamp MUST contain the date/time when the message was generated. (A separate process such as the MESH client may be responsible for sending the message at a later date/time.)
GPCM-SD-049 destination and receiver MUST NOT be present. Rather, MESH message routing will be used to route message to registered GP practice by NHS Number, DOB and Surname
GPCM-SD-050 BusAckRequested MUST contain a fixed value of false

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-051 InfAckRequested MUST contain a fixed value of false

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-052 SenderReference MUST contain the same unique identifier generated by GPCM-SD-042.

This item is found in the ITKMessageHandling extension within the ITK3 Message Header
GPCM-SD-053 Sender MUST contain a reference to an CareConnect-ITK-Header-Organization-1 resource present in the FHIR message bundle
GPCM-SD-054 Event MUST contain a fixed value of ITK008M from code system ITK-MessageEvent-2
GPCM-SD-055 Timestamp MUST contain the date/time when the response was generated.
GPCM-SD-056 all messages sent through this use case MUST use MESH automated message routing in order to ensure that the message is routed correctly to the registered practice of the patient
GPCM-SD-057 each instance of a Send Consultation Report message MUST include the following MESH Workflow ID in the MESH message metadata: GPFED_CONSULT_REPORT
GPCM-SD-058 each instance of an acknowledgement message generated as a result of receipt of a Send Consultation Report message MUST include the following Workflow ID in the MESH message metadata: GPFED_CONSULT_REPORT_ACK
GPCM-SD-059 From_DTS MUST contain the MESH mailbox ID of the sender of the message – in this case the originating GP practice
GPCM-SD-060 To_DTS MUST contain the NHS Number, DOB and Surname of the patient delimited by the underscore character ‘_'. This enables automatic routing of the message to the registered GP MESH mailbox
GPCM-SD-061 Subject MUST contain To text in the following format:

Consultation report for {Patient Name} , NHS Number {NHS Number}, seen at {Practice Name}, ODS Code {ODS Code}
GPCM-SD-062 Mex-From MUST contain the MESH mailbox ID of the sender of the message – in this case the originating GP practice
GPCM-SD-063 Mex-To MUST contain the NHS Number, DOB and Surname of the patient delimited by the underscore character ‘_'. This enables automatic routing of the message to the registered GP MESH mailbox
GPCM-SD-064 Mex-Subject MUST contain To text in the following format:

Consultation report for {Patient Name} , NHS Number {NHS Number}, seen at {Practice Name}, ODS Code {ODS Code}
GPCM-SD-065 where the received message does not conform to the requirements stated for ITK3 header, or for the payload, the message MUST be considered invalid
GPCM-SD-066 where a received message is invalid, an ITK3 Response MUST be generated, with the corresponding Negative ITK3 Response Code which indicates the nature of the error, and the message MUST NOT be accepted for downstream processing
GPCM-SD-074 error context and description MUST be provided in the OperationOutcome.diagnostic element to enable the sender to correctly identify the error which has been found in their sent message
GPCM-SD-075 the following errors, when encountered, MUST be handled gracefully by the message sending system
GPCM-SD-076 a Send Consultation Report message MUST be sent for 100% of practice encounters to ensure that the registered practice care record is an accurate statement of care delivered in a primary care setting
GPCM-SD-077 the Send Consultation Report send facility MUST be implemented in such a way as to minimise administrative burden on the practice
GPCM-SD-083 Step 1 - if the patient registration type of the patient record at the appointment hosting practice is Regular (GMS/PMS), meaning, the registered practice care record is already up-to-date, then a message MUST NOT be sent
GPCM-SD-084 Step 2 - a PDS lookup of the patient MUST be performed to determine the ODS code of the registered practice of the patient
GPCM-SD-086 the provider system MUST include all data entered by the clinician at the sender practice into the 'Clinical notes [notes]' section of the PDF document. This includes all free text, clinical/SNOMED CT codes, dm+d codes and any other data entered relating to the consultation
GPCM-SD-087 data MUST be displayed in a format that matches how the consultation is displayed on screen or when printed
GPCM-SD-088 the provider system MUST include in the message all attachments relating to the consultation
GPCM-SD-089 where the system does not have a concept of a consultation in its architecture, then the provider system MUST consider all data asserted about the patient for a specified date as part of the same consultation (this follows the same model as GP2GP)
GPCM-SD-090 the layout and content of the PDF MUST conform to the template and logical field model contained in the Layout section below
GPCM-SD-091 the version number MUST be displayed in the PDF in the relevant field and within the Subject of the MESH .CTL file
GPCM-SD-092 when displaying the consultation report in the practice workflow/task list, the message receiver MUST display the Subject contained in the MESH .CTL file:
Consultation report for {Patient Name} , NHS Number {NHS Number}, seen at {Practice Name}*, ODS Code {ODS Code}*
* these items MUST NOT be displayed if the consultation has been flagged as confidential
GPCM-SD-093 the message receiver MUST make any attachments included with the consultation report available to the end user
GPCM-SD-094 where a consultation report is not successfully received/managed by the message receiver, the sender system MUST inform an appropriate person
GPCM-SD-095 where either the infrastructure or business acknowledgements, or both, are not received for a consultation report, the sender system MUST inform an appropriate person
GPCM-SD-096 the message sender system MUST send the consultation report within 3 hours after the consultation was created or last update
GPCM-SD-135 the sender system MUST give a warning message to the user. The warning message MUST include the patient name, NHS number, consultation date and the patient's registered GP practice
GPCM-SD-098 version 1 is the original report, each subsequent report that relates to the same consultation MUST increment by 1
GPCM-SD-102 if the patient has requested that the consultation is confidential then the following data items MUST NOT be sent in the PDF: Clinical Notes, Clinician, Surgery Tel No., Surgery Email, Place of consultation
GPCM-SD-133 if the local system supports setting individual data items as confidential, then each item flagged as confidential MUST contain the warning text Confidential item when sent in the consultation report
GPCM-SD-134 if multiple data items are flagged as confidential, the warning text Confidential item MUST be repeated for each item
GPCM-SD-126 Receivers of replacement documents MUST process the replacement document and archive the replaced document
GPCM-SD-127 the receiver of the new document SHOULD mark the original and replacement document as null and void and report a error to the sender using the ITK Response message and appropriate code see ITK3 response codes for further information
GPCM-SD-128 the sender of the new document SHOULD mark the original and replacement document as null and void once it receives the ITK3 Response indicating that the replacement document could not be processed
GPCM-SD-129 replacements MAY be done more than once and the new document always refers to the previous document, multiple replacements SHOULD be avoided due to complexity of maintaining the audit trail
GPCM-SD-130 replacement documents SHOULD be sent within 24 hours of the original document
GPCM-SD-131 Composition.relatesTo.code MUST contain the fixed value replaces
GPCM-SD-132 Composition.relatesTo.targetIdentifier MUST contain the identifier of the old document - UUID of original document
None None applicable
GFR Generic FHIR receiver
ITK ITK
Tags: use-case

All content is available under the Open Government Licence v3.0, except where otherwise stated