How to develop local specifications

This guidance is intended to support purchasing authorities (such as CCGs) to develop suitable local specifications for online consultation solutions. It should be used in conjunction with other good practice guidance on procurement.

Procurement scope

The CCG should be clear if it wishes to procure a digital solution only or a managed service which includes a digital solution and clinical services. Note the central funding is only available to support procurement of the digital solution and any necessary enabling and deployment functions. Other services if included in the procurement would need to be funded locally. Ongoing revenue costs beyond the period of funding provided under the General Practice Forward View would need to be funded locally.

Where there is more than one practice intended as the recipient user of the online consultation solution the number of practices and their respective registered patient list sizes should be fully scoped and stated. Only online consultation services which support patients registered with the general practices included within this procurement are in scope. Private online GP and prescribing services which operate independently of these general practices are not in scope.

Functional requirements specification

The following functions are essential for a solution to be eligible for this funding:

  • Connection via web browser, mobile app or both. Apps should be accessible to patients without payment.
  • Functionality to allow the patient to enter a query, symptoms or other information and for this to be transmitted securely to their registered GP practice.
  • Information provided by patients used for clinical purposes must be capable of being imported back into the GP practice system with minimal manual intervention.

Some systems on the market offer additional functions which are not essential, including:

  • Functionality to provide or signpost the patient to information relating to their query or symptoms. This may include information about conditions and treatment or about local health, care and support services.
  • Inclusion of a video or phone consultation feature.

Technical and Security Requirements Specification

  1. Supporting Clinical Safety

a. The bidder should confirm that

i. If the solution (or part of) is not classified as a medical device then the manufacturer/developer of the online consultation solution has applied clinical risk management as required under SCCI0129 (formerly ISB 0129 Clinical Risk Management: its Application in the Manufacture of Health IT Systems) during the development of the product. The bidder should also be able to provide assistance to the practice (and its local IT provider) in the application of clinical risk management as required under SCCI0160 (formerly ISB 0160 Clinical Risk Management: Its Application in the Deployment and Use of Health IT Systems) during the deployment of the online consultation solution.

ii. If the solution (or part of) is classified as a medical device the solution complies with the medical device directives.

b. If the solution uses a clinical decision support tool (i.e. utilising predefined algorithms and / or a knowledge base) for direct use by the patient or a remote clinician, then details on the provenance and validation of this tool should be provided by the bidder, together with Clinical Safety Assurance.

  1. Data Processing Responsibilities

If the solution is hosted (externally to the practice) by the bidder or the bidder acts as a data processor of patient identifiable information the bidder must:

a. Confirm they can provide Information Governance assurances for their organisation via the NHS Information Governance Toolkit (using the applicable IG Toolkit version eg ‘Commercial Third Party’, an ‘NHS Business Partner’, an ‘Any Qualified Provider’).

b. The organisation holds, a current Cyber Essentials (CE), as a minimum preferably Cyber Essentials Plus (CE+), certificate from an accredited CE Certification Body

c. Describe how the online consultation system will support individual general practice(s) discharge its legal responsibilities as data controller, in particular:

i. How data sharing between legal entities e.g. individual practices can be controlled;

ii. How the practice can respond to a Full Data Disclosure Request made by a patient under the UK Data Protection Act or EU General Data Protection Regulation (GDPR) at no charge to the patient;

iii. That a record access audit log is automatically maintained in the system. This audit log should be readily accessible by the practice as data controller to allow the practice to respond to patient requests for this information (as committed in the NHS Patient Care Record Guarantee) or to any authorised information security or governance investigations.

iv. Where patient identifiable data is hosted externally by the bidder (or one of its subcontractors) the bidder should confirm the data is held securely within the U.K.

v. Fully support the practice, and its commissioned GP IT Service delivery partner, detect, report and investigate personal data breaches complying with the requirement to report specific breaches to the ICO within 72 hours of becoming aware of such a breach

d. Confirm it can comply with the National Data Guardian’s Data 10 Security Standards.

e. Confirm that as a Data Processor they will be compliant with the EU General Data Protection Regulation applicable in the UK from 25 May 2018. This compliance will include keeping records of data processing activities. 

  1. Interoperability with Principal GP Clinical Systems

The proposed solution must be interoperable with the general practice principle clinical system so that data is electronically transferred into the  clinical system without manual data entry (re-keying) being required.

This is an area where software functionality and interoperability is evolving fast. Procurement should seek to secure the best solution currently available.

a. Where clinical data (history, diagnosis, symptoms, findings, diagnostic investigations and results, treatment, prescribed drugs) is exchanged electronically using a formal clinical coding system between the online consultation system and the GP principal clinical system the data should be in approved clinical term nomenclature such as SNOMED CT. NB:  From April 2018, SNOMED CT must be adopted by all general practice service providers.

b. If the bidder’s proposed solution will interface directly with the GPSOC principal clinical system in the practice, the system should use the verified NHS number as the primary identifier and in any documented outputs of patient identifiable information.

c. The bidder’s proposed solution will either

i. Directly interface with the GPSOC principal clinical system in the practice using the NHS Digital GPSOC GP Connect platform and FHIR standard the bidder should hold a Licence for the Digital Interoperability Platform from NHS Digital.

Or

ii. The bidder’s proposed solution uses a different interoperability platform then (i) this platform should be stated (ii) any standards on which it is based should be stated (iii) confirmation is required that the interoperability is approved and supported by the principal clinical system supplier(s) (iv) the bidder should commit to migrating to the NHS Digital GPSOC GP Connect platform and FHIR standard if that becomes mandated in the future.

d. If the bidder’s proposed solution will interface with the NHS111, GP out of hours or Integrated Urgent Care principal clinical system using the Interoperability Toolkit, the bidder should hold the relevant authority from NHS Digital. If the bidder’s proposed solution uses a different interoperability platform then (i) this platform should be stated (ii) any standards on which it is based should be stated (iii) confirmation is required that the interoperability is approved and supported by the principal clinical system supplier(s) (iv) the bidder should commit to migrating to any NHS 111 Online technical standards that are issued in the future

  1. Patient Identification and Authentication
    This is an area where software functionality and interoperability is evolving fast. Procurement should seek to secure the best solution currently available.

a. The solution design should mitigate against the risk of unauthorised disclosure of personal confidential information. This might include face-to-face interaction over video, or steps to verify or authenticate the identity of a user such as an existing patient verification process used for patient on line services.

b. The solution should support practices follow the good practice guidance in Patient Online Services in Primary Care – Good Practice Guidance on Identity Verification

c. Where the system supports account-based access, it should require a separate identity authentication if access is to be made on behalf of the patient by a proxy such as a carer or care home worker. This patient proxy verification should meet the same standard as used for patient identity verification.

d. Bidders should confirm they will ensure their solution will be compliant with future NHS or Government standards on data and cyber security and patient identity verification including the integration with any future mandated single or common patient identity management service.

  1. Management of stored patient records

Where patient records are stored as part of the online consultation solution the bidder should describe how the following scenarios will be managed:

a. On changing registered general practice

b. On patient becoming deceased

c. Other patient identity management issues (name change, gender reassignment, legal protections)

d. On termination of the online consultation solution contract (to include repatriation of the patient identifiable data to the data controller)

e. On the bidder (or a subcontractor) ceasing to trade

f. On the bidder ceasing to use a subcontractor (eg clinician) in the delivery of the service.

g. Supporting patients to exercise rights of rectification, erasure (the right to be forgotten), restriction, data portability and, objection to processing as part of GDPR compliance.

  1. IT software and equipment

a. Software (including apps) for use on desktop PCs, tablets and mobile devices as part of the bidder’s solution must be functionally compliant with current supported operating systems and internet browsers. Bidders should explain how this compliance will be maintained and supported through the product life.

b. Where the bidder (or its subcontractors – including clinicians) uses any desktop PCs, tablets or mobile devices in providing the service any patient identifiable data stored on these devices should be encrypted and backed up in real-time or near real-time to either the practice GPSOC clinical system or a secure, resilient off-site data storage service to a standard of at least tier 3 data centre. Bidders should also ensure that unsupported operating systems and internet browsers are not used on these devices to access the online consultation system.

c. The bidder is responsible for the security of any desktop PC, tablet or mobile device used within its organisation or by any of its subcontractors (including clinicians) in the provision of the online consultation service. This includes the responsibility for the removal of any patient identifiable data held on these devices.

  1. Communication Platforms
  • The online consultation should manage GP-Patient communications using a web browser and/or an App, as the primary communication platform.
  • Communications should utilise end-to-end encryption of data in transit, for example Transport Layer Security (TLS). The online consultation may also utilise other platforms as part of an integrated solution such as secure email, video conferencing, instant messaging or telephony.
  • There should be no direct charge to the patient for access to the online consultation service or technologies. Whichever platform is used the criteria previously described should still apply.
  1. Reporting
  • Practices will require simple access to online consultation utilisation and process data as standard reports. Example useful data to support practices might include patient registrations, online consultation requests and outcomes eg completed, abandoned, follow up appointment booked, and activity data such as days of week and times of day.

Non-compliance 

Where the solution does not meet these requirements the commissioner should evaluate the impact, in particular with regard to any clinical or information governance risks including ensuring general practices can meet their legal obligations as data controllers, and if necessary seek assurance from the solution supplier on commitment to future compliance.