patient-duplicates.md

Unique NHS Number

• How to enforce at the data model layer whilst being compatible with cohorts?
  1. Currently sits in generic identifier table - this is hard to constrain at the model layer.
  2. Could be an attribute on the table - easier to constrain but NHS-specific. Would need to split NHS specific fields using inheritance.
• How to enforce at the API layer?
  • If (1) above then would need to do an explicit lookup in the serializer to check uniqueness.
  • If (2) above then can use standard handling.
• How to communicate correct error to UI?
  • This should be a 400 - will need an extra message or code to distinguish.

Missing NHS Number

Three abstract fields:

1. nhs_number - str
2. missing_nhs_number_reason - concept
3. missing_nhs_number_detail - str

Note: Given we will need the latter two fields, we likely won't get any advantage by keeping nhs_number as a generic identifier. to discuss with charlie.

Validation rules

If (1) then (2) and (3) must be blank.

If not (1) then (2) must not be blank.

If (2) is not other then (3) must be blank.

If (2) is other then (3) must not be blank.

NHS Number Auth

Rules

• Any user can create a patient with an NHS number, subject to constraints above.
• Only a superuser may edit/add an nhs number on an existing patient.

Possible solution

• Suggest splitting out an API for NHS Number editing: /patient/{uid}/nhsnumber

{
    "nhs_number": "123456789",
    "missing_nhs_number_reason_cid": null,
    "missing_nhs_number_detail": null,
}

• GET and PUT methods - anyone can GET, only superuser can PUT.
• Validation as specified in [Unique NHS Number] and [Missing NHS Number].

Error modes around NHS Number

1. I supplied NHS number and its not unique
2. I didn't supply NHS number and didn't supply a reason
3. I didn't supply NHS number and supplied other reason without description

There are other error modes which the UI should avoid:

1. I supplied NHS number and I supplied a reason for not supplying it
2. I supplied a specific reason and I supplied an extra description

API Change Options

Move NHS number

With NHS number

{
  "nhs_number": "1234567",
  "missing_nhs_number_reason_cid": null,
  "missing_nhs_number_reason_description": null,
  "identifiers": [
    {
      "type": "local_id",
      "value": "1234567",
      "created_by": "b32ba554a83440ffae27c99027fb3a07"
    }
  ]
}

Without NHS Number

{
  "nhs_number": null,
  "missing_nhs_number_reason_cid": "37aedd9022564eb399bf05c4ecfdbae6",
  "missing_nhs_number_reason_description": null,
  "identifiers": [
    {
      "type": "local_id",
      "value": "1234567",
      "created_by": "b32ba554a83440ffae27c99027fb3a07"
    }
  ]
}

Pros

• Guaranteed uniqueness
• Reduction in existing complexity
• Easier to validate missing reason logic
• API updates required, but API specification easier to understand

Cons

• NHSE specific fields on Patient model - harder for cohorts?

Keep as generic identifier

With NHS Number

{
  "identifiers": [
    {
      "type": "nhsnumber",
      "value": "1234567",
      "created_by": null,
      "missing_reason_cid": null,
      "missing_reason_description": null
    },
    {
      "type": "local_id",
      "value": "1234567",
      "created_by": "b32ba554a83440ffae27c99027fb3a07",
      "missing_reason_cid": null,
      "missing_reason_description": null
    }
  ]
}

Without NHS Number

{
  "identifiers": [
    {
      "type": "nhsnumber",
      "value": null,
      "created_by": null,
      "missing_reason_cid": "6268010a5fab4059b4e647c529034d36",
      "missing_reason_description": null
    },
    {
      "type": "local_id",
      "value": "1234567",
      "created_by": "b32ba554a83440ffae27c99027fb3a07",
      "missing_reason_cid": null,
      "missing_reason_description": null
    }
  ]
}

Pros

• Seems more generic so possibly easier for cohorts

Cons

• Can't guarantee uniqueness (requires separate SELECT and INSERT)
• Missing reason has to be added to all identifiers - possibly confusing
• Need to pass nhs number with null value even if its not present

FE

• First option slightly harder - but not massively
• Some work required for document generation for the first option
• Zone BE work required for both cases