From c09a9f3af948482f02cc04eadb30174627c3c0a9 Mon Sep 17 00:00:00 2001 From: Steve Leach Date: Tue, 4 Mar 2025 14:22:55 +0000 Subject: [PATCH 1/2] ADR for Visit Notifications --- docs/adr/0014-visits-notifications.md | 63 +++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 docs/adr/0014-visits-notifications.md diff --git a/docs/adr/0014-visits-notifications.md b/docs/adr/0014-visits-notifications.md new file mode 100644 index 000000000..689c9b63b --- /dev/null +++ b/docs/adr/0014-visits-notifications.md @@ -0,0 +1,63 @@ +# 0014 - Visit Notifications + +Decision date: 2025-03-04 + +## Status + +Decision status: Accepted + +## Context + +Private prisons are now required to provide a copy of data they collect to the MoJ, +and this includes data on visits. + +HMPPS have a general preference for all visits to be booked through DPS, though with +a recognition that this may not always be practical. + +A number of options were considered for implemented the integration points required to +support this... + +1. DPS Visits Led - Nexus is a front end (get available slots from DPS and choose one of those) +2. Nexus Led - send to DPS (DPS service accepts whatever visit Nexus provides) +3. Nexus Led - send to NOMIS (Same but send visits into NOMIS) +4. Nexus Led - send to other database (Same but send visits into a new data store) + +## Decision + +We will proceed with option 2 in the short term, and allow for implementation of option 1 +in future. + +A new API will be created that will receive a Visit notification, perform some basic +synchronous validation, and then queue the notification for asynchronous processing by DPS. + +### Rationale + +Options 3 and 4 were quickly rejected: #3 directly includes NOMIS integration which would need +to be replaced anyway, and #4 involves the creation of an entirely new, and unnecessary, component. + +Option 1 is the overall MoJ architecture preference, but it is accepted that this is likely more +development effort for all parties, and it is unlikely that we will be able to enforce it for +all prisons anyway. + +It will be challenging to implement option 1 in a manner that complies with our asynchronous +writes policy. This would be a new integration pattern for HMPPS. + +It is anticipated that in the long run both #1 and #2 will be supported, with option #1 being +the HMPPS preferred approach. + +## Consequences + +* DPS will have to accept whatever visit information is sent, as long as it passes the initial + synchronous validation performed by the Integration API. +* The prison provider system must not book the visit if the initial synchronous validation fails. +* Any problems encountered when processing the notification after the initial synchronous + validation and response will be the responsibility of HMPPS and not the prison provider. +* Neither the private prison system nor HMPPS will be able guarantee capacity and lack of + conflicts due visits being booked in multiple systems. +* Does not stop private prisons implementing visits that go against national policy. + +## Supporting Documentation + +* [Discussion Document, Google Docs](https://docs.google.com/document/d/1NA9OzNn6GEBQZCc1Ba4dllOZLwXK_NTM2uZdC607oJg/edit?tab=t.0#heading=h.exkvg6tmp7ez) +* [Integration API schema for Visit](https://ministryofjustice.github.io/hmpps-integration-api/documentation/api/index.html#schema-dataresponsevisit) +* [Visits implementation epic](https://dsdmoj.atlassian.net/browse/HMAI-2) From d5790211178ec428e1e934887dad16f04876a24b Mon Sep 17 00:00:00 2001 From: Steve Leach Date: Thu, 6 Mar 2025 17:21:57 +0000 Subject: [PATCH 2/2] Updates in response to PR comments --- docs/adr/0014-visits-notifications.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/adr/0014-visits-notifications.md b/docs/adr/0014-visits-notifications.md index 689c9b63b..70cb144a4 100644 --- a/docs/adr/0014-visits-notifications.md +++ b/docs/adr/0014-visits-notifications.md @@ -45,6 +45,8 @@ writes policy. This would be a new integration pattern for HMPPS. It is anticipated that in the long run both #1 and #2 will be supported, with option #1 being the HMPPS preferred approach. +Option 2 also offers the most flexibility for API clients, particularly if option 1 is added later. + ## Consequences * DPS will have to accept whatever visit information is sent, as long as it passes the initial @@ -52,8 +54,8 @@ the HMPPS preferred approach. * The prison provider system must not book the visit if the initial synchronous validation fails. * Any problems encountered when processing the notification after the initial synchronous validation and response will be the responsibility of HMPPS and not the prison provider. -* Neither the private prison system nor HMPPS will be able guarantee capacity and lack of - conflicts due visits being booked in multiple systems. +* It will be significantly harder for the private prison system and HMPPS to provide guarantees of + capacity and lack of conflicts due visits being booked in multiple systems. * Does not stop private prisons implementing visits that go against national policy. ## Supporting Documentation