GP Connect 1.1.1 released on 11 May 2018

Introduction

The GP Connect 1.1.1 release contains some enhancements to wording and clearer guidance. There are some changes to requirements around security and standards.

Please see below for further details.

1.1.1 changes

Core specification

  • FHIR API guidance
    • Changed guidance around the “display” field on “Reference” elements within resources to align with what providers have implement and what has been tested.
  • Security guidance
    • Changed security requirements as the protocols “TLS v1.0” and “v1.1” have been deprecated. Ciphers “AES256+SHA” and “AES128+SHA” have also been deprecated. Requirements now say to use TLS 1.2 and the remaining allowed ciphers.
    • Add links to referenced external policy documents.
  • Specification versioning
    • Added distinction between substantive and unsubstantive breaking changes and effect on the version number standard.
    • Updated the Associated technical artefacts section with ‘Interactive API documentation’ and ‘FHIR profiles’.
  • System topologies (page moved to Spine Core specification)
    • Improve clarity of system topologies page.
  • Spine Directory Service (SDS)
    • Added link to code examples
  • Resource guidance
    • Added a General element guidance section with guidance on how the address elements within FHIR resources should be populated.
    • Moved the Must-Support requirements wording from the general API guidance to this page and enhanced the requirements around population of optional fields to make it more clear around the GP Connect expectations of consumers and providers.
  • Glossary
    • Moved page under the Help and support menu item
  • Tags and External Links menu items
    • Moved under the Help and support menu item
  • General API guidance

Foundations

  • Get the FHIR CapabilityStatement
    • Updated example to be JSON
  • Register a patient
    • Updated guidance on the requirements for population of patient’s preferred branch surgery by consumers and providers.
    • Changed the requirements that a consumer “SHALL pass in telecom and address details” to “a consumer MAY pass in telecom and address details of type temp”.
  • Foundations
    • Added link to consumer code examples

Appointment Management

  • Appointment Management
    • Added link to consumer code examples
    • Wording improvements made to example scenarios
  • Appointment Management FHIR resources
    • Added a diagram to show the links between resources used within the appointment management capability.
  • Book an appointment
    • Updated error handling guidance to outline the expected error response when a slot is no longer available at the point of booking the appointment.
    • Added requirement for providers and consumers around the use of the Appointment.reason element within appointment resource
  • Read an appointment
    • Added a requirement that Appointment.reason SHALL NOT be included in the returned appointment resource
  • Retrieve a patient’s appointments
    • Added a requirement that Appointment.reason SHALL NOT be included in the returned appointment resources
    • Corrected requirement wording around returning appointments in the future, to say greater than or equal to rather than just greater than
  • Appointment Management clinical scenarios
    • Corrected wording and moved elements on page to match intended requirements and remove incorrect information, such as home visit which has been moved to out of scope for FoT.
    • General wording improvements to make meaning of scenarios more clear.
  • Business requirements
    • Appointments business requirements page added containing additional guidance around the requirements for appointment management.