Overarching PDS/DBS handling for consumers

[jonnyry]

There should be common PDS/DBS handling guidance for consumers which applies to all capabilities within GP Connect.

It should be written as a practical guide for consumers looking to use GP Connect and satisfy the PDS/DBS pre-requisite, and should refer out to PDS or DBS documentation where appropriate.

Items to cover:

• when to use PDS (once per patient per session?) / DBS (?)
• why we require the use of PDS / DBS - i.e. the purpose of it
  • finding an NHS number from demographics OR cross check/verify NHS number
  • [demographic synchronisation?]
  • checking for flagged or deceased statuses
  • retrieving the patient's registered GP practice
• which PDS transaction/message to use in which scenario:
  • trace
  • retrieval
  • cross check
• what to do in particular scenarios
  • if patient is marked as deceased
  • if patient is flagged:
  • invalid
  • business
  • sensitive
  • superseded
  • if PDS fails for any other reason
• Differences between "full" PDS and PDS mini service
• DBS specific guidance
• Technical examples (and code samples/snippits?) of using full PDS, PDS mini service & DBS
• Links PDS, PDS mini service & DBS documentation, and how to engage with those programmes where separate assurance is required
• Details on the upcoming PDS restful service, and how to contribute to this

Capabilities should link though to the overarching PDS guidance and highlight any capability specific differences required.

Also link through to PDS/DBS requirements where relevent: https://nhsconnect.github.io/spine-smsp/demographics_reqs.html

Also see overarching PDS handling for providers: https://github.com/nhsconnect/gpconnect/issues/401

[jonnyry]

Please read content of #392 before completing this ticket (and complete any actions).

[RiChallinor]

To be applied to 0.5.1 and 1.2.0 also

[jackiebarnes]

PDS S-Flagged Patients: Seems that with additional capabilities bring additional potential complexity and the current As Is, see below, we need to review whether GP Connect across the board does/does not accommodate these patients;

'As Is' Situation a) General IG spec requires that if request made for these patients, then data should be returned but the location/contact details substituted by those of the registered GP Practice b) EMIS, S1 and MTest are not complying with the spec, and instead returning a Patient Not Found operation outcome, for different reasons, but EMIS is that they can't necessarily prevent location/contact dtls being revealed in text content c) Apr 18 agreement obtained that AM capability will NOT handle these patients - see hdl-240, and #392

[jackiebarnes]

Error Handling:

Error handling This work needs to include appropriate error handling across the board for problematic -flagged patients such as S-Flagged - Find/Read a patient, Register a Patient, recognising that for AM capability there is IG agreement that the AM use case for S-Flagged patients is out of scope, therefore appropriate error msg to be returned by Prov for these APIs if it recognizes that request has been received for an S-flagged patient,

[james-answer]

In the spine error codes there is a value "PATIENT_SENSITIVE - Patient sensitive" which we could use as our error code for s-flag patients.

[jackiebarnes]

Discussing with Mike St taking the proposal to Clin Ref Group to exclude S-Flagged patient handling from GP Connect as a whole

[jackiebarnes]

ARHTML Design Decisions page needs to be aligned with resulting spec changes

[jackiebarnes]

Clin Input Group mtg of 17/4 approved decision to exclude S-Flagged patients from GP Connect, but for this issue to be raised up through broader channels in terms of how SCR/Transfer of Care etc handles; Cath Johnson to progress; Now this decision to be reflected on relevant IG, Design Decision, Impl pages