This portal provides an open platform for user feedback and product change requests. Anyone can add an idea and remain as a Guest, but please consider signing up so that others can see who has created the ideas!
Note: this is a public facing web portal, any text here can be viewed by anyone over the internet, so please consider carefully the content you wish to share and please do not post anything of a sensitive nature.
A HNY organisation (Local Authority) have requested the ability to assign users with different roles types in the Interweave portal that restrict access to data due to reduce potential for data misuse.
The use case is a team of staff called 'Technical Assistants' who work as support to the adult social care team to perform client record accuracy reviews (They are required to validate NHS numbers, so would be looking up people using name, address and date of birth to check their NHS number. We feel any further access to medical information would be inappropriate for this staff group.)
They would benefit from having access to the portal to enable them to ensure the demographic data they hold in the case tracking system is accurate (NHS numbers, DOB's etc). This would be available for the majority of their clients by accessing the demographic resource. There is no requirement for them to have wider clinical information and the LA would like to be able to allocate this team with access relevant to their need.
This functionality would be:
available via the user access management panel
ideally would be definable by the organisation - creation of new user roles that could be attributed to registered users
if not, the UAM panel would enable organisation to select from a list of predefined user roles and be able to attribute them to registered users
Apologies Debbie, this is a valid role, my mistake, we are picking this up as part of RBAC so will promote this to the feature card in Aha
Hi Debbie, P-I-34 is the task to create a full RBAC model, allowing more flexibility for tenant admins to define who see's what. In that respect, this is similar.
However, we're not committing to this particular idea as it is designed to facilitate an administrative task rather than what the Portal was designed to do
Hi Ian - I note that this idea has been marked as 'will not implement' but also that it is very similar to an idea you shared in February (P-I-34). Are you able to clarify why this won't be implemented? I've looked but could find any comments telling me why? Many thanks,
Email discussion chronologically captured to support idea development:
DEBBIE WESTMORELAND 30/08/2022:
Hi Ian
Thanks for the update to the idea I logged. I’ve emailed instead of updating the ticket to avoid it becoming a conversation…
I agree that the admin control UI dev would likely be the most efficient/effective way to manage this requirement going forward. Have the development timelines been estimated? I’m aware this isn’t just a HNY requirement and others are keen. Could the central team/Synanetics provide option 1 as an interim?
@Joseph Perry my understanding is the requirement is current/immediate and the users are waiting for access to support the teams. Would Ian’s suggestion below providing instructions to only access ‘Person’ details and not delve further be adequate in this case or would you need more assurance they were incapable of accessing further details?
IAN CLUCAS 01/09/2022:
Hi Debbie
We’ll take the full solution into backlog refinement to design and estimate, given this, and on reflection, we’d prefer not to spend time on option 1 in the hope that instruction (and the audit capability) will suffice?
DEBBIE WESTMORELAND 01/09/2022:
@Joseph Perry – will await your feedback on the string below…
JOE PERRY 05/09/2022:
Morning
Option 2 sounds like the sustainable choice, and gives us flexibility moving forward, so happy if this is the route taken. The urgency isn’t such an issue here.
Kind Regards
Joseph Perry
Senior Business Change Officer
Commissioning and Partnerships
Adult Social Care and Health
attachment
hi Debbie, a more granular RBAC model is definitely required for the Portal and we could do
create the role and apply the required permissions our side
create a UI and enable this functionality for tenant admins
option 2 is naturally the better but more complex solution and I think the one you are requesting as this enables tenancies to have the control they need
option 1 would achieve the result required here, if the requirement was particularly urgent, although these users could simply be instructed to set their home page to 'Person details' and not delve further into the system as all user activity is audited - this would then show them the person details screen rather than the Summary panels, as per attachment. That said, the confirm relationship screen may actually be sufficient?