| Page Properties | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
| Page Properties | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||
|
Background
GP Connect is initially focused on delivering synchronous FHIR® APIs for Patient Record retrieval and Appointment Booking. A new set of features, under the badge of GP Connect Messaging, is used to send and receive updates to GP practice systems. The GP Connect Messaging features are based on the FHIR standard and sent asynchronously using MESH and ITK3 technologies.
GP solutions require the following features:
- send GP Connect messages to a receiving system via ITK3/MESH
- receive GP Connect FHIR messages via the Generic FHIR Receiver
The initial messaging feature that will be supported by GP Connect Messaging, and thus defined in the existing requirements, is the Send Document feature.
Documentation
The GP Connect Messaging specification, which can be accessed via the GP Connect Messaging site, The GP Connect 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.