GP Connect - Send Document

Part of the GP Connect product family

Typical process map

CLINICIAN AT GP PRACTICE
CLINICIAN AT GP PRACTICE
PROVIDER SYSTEM
PROVIDER SYSTEM
MESH CLIENT
MESH CLIENT
CONSUMER SYSTEM
CONSUMER SYSTEM
Start
Start
1. Author patient activity
1. Author patient activity
2. Save activity
2. Save activity
3. Save "completed" activity into patient record
3. Save "completed" activity into patient record
Yes
Yes
No
No
4. Is the patient registered at this GP Practice?
4. Is the patient register...
End
End
5. Wait for a configurable amount of time
5. Wait for a config...
Yes
Yes
No
No
6. Further update to the activity required? 
6. Further update to t...
7. Generate a PDF and metadata
7. Generate a PDF an...
8. Send message via MESH
8. Send message via...
9. MESH file transfer
9. MESH file transfer
10. Retrieve message from MESH
10. Retrieve message...
11. Send infrastructure acknowledgement
11. Send infrastruct...
13. Add message
into workflow
13. Add message...
12. Receive infrastructure acknowledgement
12. Receive infrastr...
End
End
14. Send business
acknowledgement
14. Send business...
15. Receive business acknowledgement
15. Receive business...Text is not SVG - cannot display

Steps in the process explained

Step 1: Author patient activity

Clinician inputs the details of the activity into the GP provider system. Data inputted could be free text or clinical codes which may be entered manually or through the use of clinical templates. It could include adding attachments/documents (for example, pain-point diagram, ECG, photo). This is no different from the normal method of writing a activity for a patient registered at the GP practice.

Step 2: Save activity

The clinician manually saves the patient activity and commits them to the patient record.

Step 3: Save activity into patient record

The provider system saves the patient activity into the patient’s electronic record at the GP practice.

Step 4: Is the patient registered at this GP Practice?

The provider system need not send a patient activity if the patient they have seen is registered at their practice.

Step 5: Wait for a configuration amount of time

The provider system waits for a configuration amount of time (recommended three hours) before the process moves on. This gives time for the clinician to make any necessary updates to the patient activity to reduce the chance of the report being sent multiple times.

The period of time that the clinical system waits before sending a message can be configured by each GP practice to meet their local needs.

Step 6: Further updates to the activity required?

If the user makes changes to the patient activity in the patient record within the allotted time (step 5), the process moves back to step 1.

Otherwise, the process moves on to step 7.

There may be many reasons why the activity is not completed when initially saved:

  • the clinician may not have time to finish the patient activity and must continue with treating other patients
  • the clinician may wish to ask a colleague for advice
  • the clinician may be off-site and will finish writing the patient activity when they have returned to the GP practice
  • the results of a test may be required before the clinician can complete their notes
  • the clinician may have forgotten to add some important information when originally writing the patient activity
Step 7: Generate a PDF and metadata

A FHIR message is generated which contains a PDF which contains all the information recorded in the activity (including free text, clinical coding and other data entered relating to the activity).

The ITK3 FHIR Message is generated, which must include:

  • FHIR MessageHeader
  • FHIR STU3 composition
  • PDF file, its contents and metadata
  • all attachments/documents recorded with the activity

When the PDF is generated, the provider system checks for previous versions of the PDF linked to this activity.

A previous version will exist if the clinician updates the activity more than three hours after it was initially saved and committed.

  • if there are no previous versions, the PDF is designated as [version 1]
  • if there are previous versions, the PDF is designated [version 2 / 3 / 4 / ...n]
  • the version number is displayed in the title of the PDF: [document title] Version [x] and the version field within the document itself
Step 8: Send message via MESH

The provider (sending) system passes the message to the MESH client.

Step 9: MESH file transfer

The MESH client transfers the message to the MESH inbox of the patient’s registered GP practice.

Step 10: Retrieve message from MESH

The consumer (receiving) system of the registered practice retrieves the message from their MESH inbox.

Step 11: Send infrastructure acknowledgement

The consumer system sends an ITK3 FHIR Message to the provider system containing:

  • FHIR MessageHeader
  • FHIR OperationOutcome (ITK3 response with response code 10001 to 20013)
Step 12: Receive infrastructure acknowledgement

The provider system records the infrastructure acknowledgement. If no acknowledgement is received within a reasonable timeframe (to be defined by system supplier), the provider system notifies an appropriate end user.

Step 13: Add message into workflow

The consumer system matches the message to a registered GP patient and presents the message to an appropriate user in a designated workflow.

Step 14: Send business acknowledgement

The consumer system sends an ITK3 FHIR Message to the provider system containing:

  • FHIR MessageHeader
  • FHIR OperationOutcome (ITK3 response with response code 30001 to 30003)
Step 15: Receive business acknowledgement

The provider system records the business acknowledgement. If no acknowledgement is received within a reasonable timeframe (configurable), the provider system notifies an appropriate end user.

back to top