Introduction

This page Identifies the key differences between the CareConnect API specification and the GP Connect API specification. It is imprtant to note that the CareConnect standard is under development and some of these items may change so please keep reviewing this page. It is also not comprehensive and only covers the significant changes, there may be some small detail differences that are not documented here.

Identify Patient

GP Connect

Use PDS to get a verified NHS Number

CareConnect

Use PDS to get a verified NHS Number

Difference

No Change

Rationale for change

NA

Select Service

GP Connect

Get Registered GP Practice from PDS record

CareConnect

Use DoS to select a DoS profile

Difference

In GP Connect, this is done as part of the PDS lookup, in Care Connect, it is a separate call to the DoS, but one which is MOSTLY already taking place.

Some change needed to the DoS to return the ASID.

Rationale for change

GP Connect is all about booking appointments with a GP Practice, which is a known ODS code.

CareConnect is looking beyond this to services as identified from the DoS, or by ASID.
These can also be found from SDS using ODS code.

Calls via SSP

GP Connect

Target URL is concatenated onto SSP URL

http headers are as follows:

Ssp-TraceID

Ssp-From

Ssp-To

Ssp-InteractionID

Authorization

CareConnect

Target URL is concatenated onto SSP URL

http headers are as follows:

Ssp-TraceID = a UUID

Ssp-From = Client system ASID

Ssp-To = Server ASID

Ssp-InteractionID = Interaction ID from SDS specific to the call being made.

Authorization

Difference

Calls via SSP: No change
Interaction ID's are different in http headers
Ssp-TraceID: no change
Ssp-From: no change
Ssp-To: no change
Ssp-InteractionID: specific set for GP Connect and another for CareConnect
Authorization: Both uses JWT token in an Authorisation http header (not used by SSP) however CareConnect token is signed and is issued by an auth server. GPC is unsigned and created by the consumer system. Care connect includes Group values which represent groups. GPC has a set of claims.

Rationale for change

Target URL is concatenated onto SSP URL
The Interaction IDs are different to allow them to be individually authorised, and to permit different endpoints to be offered per interaction. If there were no differences elsewhere they COULD be the same.


SSP Could inspect the Authorization header and make decisions based on that (not currently in scope).

TLS/MA

GP Connect

Spine issued digital certificate required to talk to PDS, SDS and SSP

CareConnect

Spine issued digital certificate required to talk to PDS, SDS and SSP

Difference

No change

If the client is only assured for appointment booking, a certificate with a specific prefix will be issued, to prevent it being used to do anything else.

Rationale for change

NA

SSP authorisation

GP Connect

Uses the following:

SDS lookup for ASIDs
Data Sharing agreement between Client and Server

CareConnect

Uses the following:

SDS lookup for ASIDs

Difference

No Data Sharing Agreement required for CareConnect

Rationale for change

For MVP CareConnect is not requesting Patient info, hence lower IG concerns. The DSA approach doesn't scale for any-to-any booking as the scope expands.

Could be implemented in Authorization headers rather than config file.

Find Patient

GP Connect

FHIR Search operation on the endpoint via SSP

GET https://[proxy_server]/https://[provider_server]/[fhir_base]/Patient?identifier=[system]|[value]
NB: in the above [system] will always be https://fhir.nhs.uk/Id/nhs-number and [value] will always be the NHS Number

CareConnect

Not used

Difference

Patient find is not used in Care Connect

Rationale for change

GP Connect works on the GP concept of patients being registered in a practice. Many other services will not have this concept.

Register Patient

GP Connect

Patient is registered if not found.

CareConnect

Not used

Difference

Register Patient is not done in Care Connect

Rationale for change

If the service requires a patient to be registered, it can perform this within the atomic booking process, rather than have a separate routine.

Find Endpoint

GP Connect

Use SDS to get endpoint from nhsMHS object

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk –b "ou=services, o=nhs" "(&(nhsIDCode=T99999) (objectClass=nhsAS)(nhsAsSvcIA=urn:nhs:names:services:gpconnect:fhir:rest:search:slot-1))" uniqueIdentifier nhsMhsPartyKey

T99999 = ODS Code of the GP Practice

gpconnect:fhir:rest:search:slot-1 is the Interaction being performed

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk -b "ou=services, o=nhs" "(&(nhsMhsPartyKey=T99999-9999999) (objectClass=nhsMhs) (nhsMhsSvcIA=urn:nhs:names:services:gpconnect:fhir:rest:search:slot-1))" nhsMhsEndPoint nhsMHSFQDN

T99999-9999999 is the partyKey from previous step

…:gpconnect:fhir:rest:search:slot-1 is the Interaction being performed

CareConnect

Use SDS to get endpoint from nhsMHS object

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk –b "ou=services, o=nhs" "(&(uniqueIdentifier=ABC123) (objectClass=nhsAS)(nhsAsSvcIA=urn:nhs:names:services:a2si:fhir:rest:search:slot))" nhsMhsPartyKey

ABC123 = ASID of the service as returned from DOS

a2si:fhir:rest:search:slot is the Interaction being performed

ldapsearch -x -H ldaps://ldap.vn03.national.ncrs.nhs.uk -b "ou=services, o=nhs" "(&(nhsMhsPartyKey=T99999-9999999) (objectClass=nhsMhs) (nhsMhsSvcIA=urn:nhs:names:services:a2si:fhir:rest:search:slot))" nhsMhsEndPoint nhsMHSFQDN

T99999-9999999 is the partyKey from previous step

…:a2si:fhir:rest:search:slot is the Interaction being performed

Difference

Different LDAP searches

LDAP search is based on ODS code for GP Connect, ASID for Care Connect. Interaction name is different.
The search is identical apart from the Interaction ID being specific.

Rationale for change

Knowing the ASID allows a simpler and faster / more efficient LDAP query, it also supports a more granular approach than ODS codes alone, including one server endpoint for multiple DOS profiles.

Get free slots

GP Connect

FHIR Search operation on the endpoint via SSP
GET https://[proxy_server]/https://[provider_server]/[fhir_base]/Slot?[start={search_prefix}start_date][&end=[{search_prefix}end_date][&status=free][&_include=Slot:schedule]{&_include:recurse=Schedule:actor:Practitioner}{&_include:recurse=Schedule:actor:Location}{&searchFilter={OrgTypeSystem}|{OrgTypeValue}}{&searchFilter={OrgODSCodeSystem}|{OrgODSCode}}

CareConnect

FHIR Search operation on the endpoint via SSP
GET https://[proxy_server]/https://[provider_server]/[fhir_base]/Slot?[start={search_prefix}start_date][&end=[{search_prefix}end_date][&status=free][&_schedule.actor:healthcareservice=xxxxx][&_include=Slot:schedule]{&_include:recurse=Schedule:actor:Practitioner}{&_include:recurse=Schedule:actor:Location}

Difference

No searchFilter parameter used in Care Connect, see below for more details.
Also resource profiles are different.

Rationale for change

SearchFilter is open to abuse and not needed if we use JWT (below).

Identify Requestor

GP Connect

searchFilter parameter
GET https://[proxy_server]/https://[provider_server]/[fhir_base]/Slot?[start={search_prefix}start_date][&end=[{search_prefix}end_date][&status=free][&_include=Slot:schedule]{&_include:recurse=Schedule:actor:Practitioner}{&_include:recurse=Schedule:actor:Location}{&searchFilter={OrgTypeSystem}|{OrgTypeValue}}{&searchFilter={OrgODSCodeSystem}|{OrgODSCode}}

CareConnect

JWT
See: https://developer.nhs.uk/apis/spine-core/security_jwt.html for example specification (although this is not currently implemented in a complete way and a CareConnect authorisation service is likely to deviate to some extent.

Difference

GP Connect expects an assertion of the type of organisation making the request and their ODS Code in a searchFilter querystring parameter.
Care Connect expects to get this information from a signed JWT issued by an authentication service.

JWT can be verified by checking signature.

Rationale for change

This is a combination of authentication (who is the client) and authorisation (what can they do) and therefore should be handled as such. Implementing this removes the need for searchFilter.

Using a signed JWT gives the server significant confidence in the identity of the client, which should help to reduce IG challenges.

Book an Appointment

GP Connect

FHIR Create operation on the endpoint via SSP
POST https://[proxy_server]/https://[provider_server]/[fhir_base]/Appointment

CareConnect

FHIR Create operation on the endpoint via SSP
POST https://[proxy_server]/https://[provider_server]/[fhir_base]/Appointment

Difference

Resources are (will be) different.

Rationale for change

See FHIR Resource rationale.

FHIR Resource Profiles

GP Connect

GP Connect has specific profiles

Slot Profile: https://fhir.nhs.uk/STU3/StructureDefinition/GPConnect-Slot-1

Appointment Profile: https://fhir.nhs.uk/STU3/StructureDefinition/GPConnect-Appointment-1

Patient Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-Patient-1

Location Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-Location-1

Practitioner Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-Practitioner-1

Schedule Profile: https://fhir.nhs.uk/STU3/StructureDefinition/GPConnect-Schedule-1

PractitionerRole Profile: N/A

Organisation Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-GPC-Organization-1

CareConnect

Care Connect has Generic profiles where possible

Slot Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-Slot-1

Appointment Profile: https://fhir.nhs.uk/STU3/StructureDefinition/CareConnect-Appointment-1

Patient Profile: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Patient-1

Location Profile: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Location-1

Practitioner Profile: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Practitioner-1

Schedule Profile: TBC

PractitionerRole Profile: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-PractitionerRole-1

Organisation Profile: https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Organization-1

Difference

Resources are still based on FHIR STU3 but are (or will be) different.

Rationale for change

GP Connect resources are by definition (it's part of their name) for GP Connect. Where possible CareConnect tries to use generic resources. Each has been profiled to include the necessary information.

Search for booked Appointments

GP Connect

Described
https://nhsconnect.github.io/gpconnect/ appointments_use_case_retrieve_a_patients_appointments.html

CareConnect

Emerging Capability

Difference

Emerging capability for CareConnect and currently not described

Rationale for change

IG concerns are higher, so excluded from MVP.

Cancel Appointment

GP Connect

Described
https://nhsconnect.github.io/gpconnect/ appointments_use_case_cancel_an_appointment.html

CareConnect

Emerging Capability

Difference

Emerging capability for CareConnect and currently not described

Rationale for change

IG concerns are higher, so excluded from MVP.

Amend Appointment

GP Connect

Described
https://nhsconnect.github.io/gpconnect/ appointments_use_case_amend_an_appointment.html

CareConnect

Emerging Capability

Difference

Emerging capability for CareConnect and currently not described

Rationale for change

IG concerns are higher, so excluded from MVP.