| Page Properties | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
| Page Properties | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
|
Background
Summary
The GP Connect is initially focused on delivering synchronous FHIR® APIs for patient record retrieval and appointment booking. A new set of capabilities, under the badge of GP Connect Messaging, is used to send and receive updates to GP practice systems. The GP Connect Messaging capabilities are based on the FHIR standard and sent asynchronously using MESH and ITK3 technologies.
GP solutions require the following capabilities:
- send GP Connect messages to a receiving system via ITK3/MESH
- receive GP Connect FHIR messages via the Generic FHIR Receiver
The initial messaging capability that will be supported by GP Connect Messaging, and thus defined in the existing requirements, is the Send Document capability.
Documentation
The GP Connect Messaging specification, which can be accessed via the GP Connect Messaging site, capabilities support the development of products that enable different systems to communicate so that clinicians in different care settings can:
- view a patient’s GP practice record with Access Record: HTML
- manage GP appointments with Appointment Management
- import or download Patient data with Access Record: Structured
- send a consultation update back to the GP Practice System with GP Connect Messaging Send Document
The GP Connect Messaging Send Document capability provides a simple and standardised means of sending and receiving a document containing a consultation update to a GP Practice system, helping to ‘close the loop’ and provide latest information to the patient’s registered GP.
Summary of Change
To understand the full scope of changes made since a given specification you should read all the subsequent release notes.
Full Specification
The GP Connect Messaging specification describes the messaging approach being taken by GP Connect for record update scenarios. These will need implementing alongside the Generic FHIR Receiver component requirements.