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 |