Test Approach Foundations & Appointments

Below is the suggested implementation order which developers SHOULD follow when implementing the GP Connect Foundation and Appointment Management API functionality. The specified order has been constructed around the functionality of the GP Connect Automated Test Suite, looking at the API Endpoint dependencies within the test scenarios.

It is advisable to develop against the Automated Test Suite as this will assist with creating a GP Connect compliant product. By implementing the endpoints in the order below, this means that the specific set of tests for that endpoint can be run during development without the developer seeing errors due to pre-test api calls or post test validation api calls relevant to the test being run.

1. Foundation Endpoints

Order	API Endpoint	Test Suite Endpoint Dependencies	Reason For Dependency
#1	Find an organization	-	The find an organization capability is not dependent on any other capablitiy within the automated test suite.
#2	Read an Organization	Find an organization	Find an organization is a dependancy for Read an organization as it is used to lookup the local identifier from the organization code which is setup in the test suite organization mapping csv file.
#3	Find a practitioner	Read an Organization	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource.
#4	Read a practitioner	Find a practitioner, Read an organization	Find a practitioner is required to lookup the logical identifier, from the practitioner user id setup in the test suite practitioner mapping csv file, to use for the read. The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource.
#5	Find a patient	Read and organization, Read a practitioner	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the practitioner resource. The Read a practitioner endpoint is required to validate the “careProvider” reference if returned within the patient resource.
#6	Read a patient	Find a patient, Read an organization, Read a practitioner	Find a patient is required to lookup logical identifier from the patient from the nhs number set up in the test suite nhsNoMap csv file. The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the patient resource. The Read a practitioner endpoint is required to validate the “careProvider” reference if returned within the patient resource.
#7	Read a location	Read an organization	The Read an organization endpoint is required to validate the “managingOrganization” reference returned within the location resource.
#8	Register a patient	Find a patient, Read a patient, Read an organization	The register patient endpoint tests require a number of the foundation search and read endpoints to be implemented and therefore it is advised that this is done as the last foundation capability. The foundation endpoints are used to create rich register patient requests as well as validating the registered patient resource is valid and retrievable on the providers system.

2. Appointment Management

Appointment Management Capability test scenarios are dependant on the Foundation capabilities and therefore the Foundation endpoints should be developed and tested before implementing the Appointment Management capabilities.

Order	API Endpoint	Test Suite Endpoint Dependencies	Reason For Dependency
#9	Search for free slots	Read an organization, Read a practitioner, Read a location	The Search for free slots test scenarios requires a number of the foundation endpoints in order to validate references within returned resources contained within the response bundle.
#10	Book an appointment	Register a patient, Find a paitent, Search for free slots, Read an organization, Read a location, Read a practitioner, Read a patient	The Book an appointment endpoint finds a slot which it then uses to book an appointment for a known patient. To find the logical id's of the elements required to book an appointment it requires the Find a patient and Search for free slots endpoints to have been implemented and working. Some of the tests also require the Register a patient endpoint to have been implemented as it tests booking an appointment against a GP Connect temp patient.
#11	Retrieve a patient appointments	Search for free slots, Find a patient, Book an appointment, Register a patient, Read an organization, Read a location, Read a practitioner, Read a patient	The test suite builds the appointments for a patient before testing the Find a patients appointments capability to make sure appointments exist to find. This requires the endpoints to find free slots, find a patients logical identifier, book an appointment and in some tests create a temporary patient against which to book the appointment.
#12	Amend an appointment	Search for free slots, Find a patient, Book an appointment, Register a patient, Read an organization, Read a location, Read a practitioner, Read a patient	The test scenarios for the Amend an appointment capability require most of the  foundation endpoints and most of the other appointment endpoints to be implemented in order to find or create the appointments which the tests are going to update as part of the Amend an appointment tests.
#13	Cancel an appointment	Search for free slots, Find a patient, Book an appointment, Amend an appointment, Register a patient, Read an organization, Read a location, Read a practitioner, Read a patient	The test scenarios for the Cancel an appointment capability require most of the  foundation endpoints and the other appointment management endpoints to be implemented in order to find, create and amend the appointments required for the test scenarios and validation of the returned response.
#14	Read an appointment	Search for free slots, Find a patient, Book an appointment, Amend an appointment, Cancel an appointment, Register a patient, Read an organization, Read a location, Read a practitioner, Read a patient	The test scenarios for Read an appointment require a number of different foundation and all the other appointment endpoints to be implemented as the tests need to create appointments with different statuses if they are not available and the test has to find the local identifiers for both the appointment it is trying to read and any steps it may need to do to create or validate the appointment.