Good afternoon. A new Information Standard was published recently on the 12th September 2023, DAPB4019: Reasonable Adjustment Digital Flag, which requires providers to have full conformance by 30th June 2024 (so roughly 9 months).
In order to achieve these timelines, there are a number of activities which need to take place, EPR system design/update/testing as well as Trust adoption and rollout.
The 9 month timeline will be challenging at best, however the FHIR APIs to access the Reasonable Adjustment Information, as detailed here, indicate that these APIs are still in development and subject to ābreaking changesā and are not yet ready for production use - please see below. As a major supplier of EPR solution to the NHS, how we can expect to be able to achieve compliance with the ISN dates when the underlying APIs are not ready - please can you clarify the status in regards to this.
RA Flag is going through First of Type (FOT) supplier integration / accreditation for RA Flag API. Once that supplier is through (expected mid November 23) then we will be welcoming all suppliers to connect.
The RA Flag API Team are very keen to talk to all suppliers about integration and especially those provisioning Shared Care Record (SCR) solutions.
RA Flag Programme run a forum for suppliers who have shown interest in connecting to RA as Fast Followers.
Also as a follow up question @alan.rawlings2, is there a dependency on using the PDS FHIR APIs in order to use the RA Flag APIs ? Reason for asking is that our EPR is currently integrated with PDS but using the āoldā HL7 messaging standards (2006-A compliance).
Thanks Alan, we are keen to understand any dependencies on the PDS FHIR APIs and also, given the timelines in the new Information Standards Notice are quite aggressive for full integration (30th June 2024), we are keen to understand how we engage with the NSHE team as a fast follower so we have the appropriate support and resources in place for the onboarding and assurance activities. Given this ISN will affect many suppliers, we are just keen to ensure there is sufficient capacity in the assurance teams to support us with the relevant activities so we can support our NHS customers on meeting the June 24 date.
Hi Lee,
Iām Clare the Lead Product Owner for our Clinical Services of which RA flag is one.
Many thanks for your interest in RA Flag, we look forward to working with you. Youāll be pleased to know that we have already had some early engagement with The Access Group with regard to RA Flag via Ashwini who attended our inaugural āTechnical Task & Finish Meetingā. Iād be happy to schedule a meeting for ourselves and our TA so we can discuss any questions or concerns you may have around technical implementation, please just contact me to set this up - Ashwini will have my details. We also provided a paper via the Task & Finish meeting around options for bulk load process, so it would also be good to catch up on your opinions and preferences around that topic. I look forward to hearing from you. Clare.
Can anyone provide an update on progress with the API? Pressure is now being asserted through ICS leadership into individual programmes of work, and all are looking for clarification to understand if delivery timescales are achievable.
I am also keen to understand more around the authentication requirements. This is a concerning area, if Smart Cards are to be a requirement.
Hi @clarecooke are you able to advise on this question from Ian please and I have a related question.
In terms of authentication, we have a number of Trusts using our EPR who are not currently connected to the NHS Spine and do not authenticate with NHS Smartcards - which is a dependency based on the NHSE RA API documentation:
For sites who are unable to use this API or the NCRS (which also requires Smartcards) to access/record RA Flag information, is there any guidance in terms of how Trusts should seek to fulfil their obligations to fully comply with the Information Standards Notice (DAPB4019: Reasonable Adjustment Digital Flag - NHS Digital) or is the expectation that all Trusts will have a plan to connect to the Spine and adopt Smartcards (CIS2) for authentication ?
Any guidance would be great so we can update our customers with the right info.
Thanks
Lee
To further add to your point Lee, as a Shared Care Record, that is further complicated by being a middleware solution. Users may well have authenticated at Trust with a Smart card, but that is not being captured through authentication into the ShCR. None of the CIS2 authentication approaches really support/work in this middleware setup. Reasonable adjustments is just one in a line of capabilities that are increasingly an issue without further clarification; NRL, CP-IS etc.
We also canāt forget that ShCRs go wider than the NHS Trust estate, where RA functions simply donāt exist. Do we just preclude these users from seeing this valuable information?
Hi Ian (& Lee),
Apologies for the late response to your initial request Ian.
Thanks for your questions. We are now looking to make RA Flag API App Restricted in order to remove that dependency on Smartcards. We are hoping to do this work in early January '24 for RA to align with Supplier onboarding activity. I was hoping this would be good news for you both. This approach is similar to the one we have applied for our new NRL offering, there is currently work ongoing around integrating Shared Care Records and NRL. However, after reading your text (Ian) āNone of the CIS2 authentication approaches really support/work in this middleware setup.ā Iām a bit concerned. Does the App restricted approach not solve the issues for you? Iād be really keen to understand more if that is the case. Happy to set up a meeting to discuss.
Thanks for the reply. App restricted sounds ok. I may have been too ālooseā in saying no CIS2 will work. I was referring more to the 6 authenticator options currently listed under CIS2. Iād be interested to have a discussion on this. From what I was hearing around NRL, the user would still require additional authentication at the point they attempt to consume - i.e. NRL in an ShCR environment can show a flag that something exists, but that cannot be consumed until the user does an additional authentication. I donāt see this approach working, or really considering how users are consuming within an ShCR environment. Any additional steps to the user will be a barrier they are unlinkely to use. If this problem stems right back to source, we need to have some honest conversations across the national estate about the right resolution, and not work arounds.
Hi Ian,
Iāve contacted some of my colleagues in Identity and Access Management to see if they can pick up this thread and/or facilitate a conversation as it leans more into their area. I will follow the outcome with interest though as this potentially impacts usage for my services.
Hi @clarecooke, thanks for your continued support; our engineering team are now preparing to start our integration works in January. They have the details of the RA APIs but asked today if there is a sandpit/test harness environment they can use for developer testing - is there such an environment available please ? Weāll use the normal INT Spine for our formal testing prior but our developers donāt typically have direct access to this. Thanks
Hi Lee,
If they contact ITOC, that team should be able to advise and sort your teams out with access to the appropriate environments: itoc.supportdesk@nhs.net
Thanks Clare. Is that the official NHS England position now and suppliers can develop on the assumption of app restricted for read and write with the RA FHIR API?
Hi Clare. The Sandpit API environment seems to be unavailable. I receive this error with Postman queries that were Ok last year:
ā503 Service Temporarily Unavailableā
Youāll notice that the test page fails too. Hitting the āTryā button returns āResponse Status: Failed to fetch (CORS or Network Issue)ā
Hi Simon,
Iām really sorry about this, thanks for bringing it to my attention. Iāll track down the responsible team and make them aware. We will update you asap.
