| Text Only |

A A A |

Monday 21 May 2012

«Our own service users

Managing the issues

Changing our policies

Creating new guidelines

We reviewed a number of relevant policies to ensure that service user employees were treated the same as other staff and volunteers, in particular, that their client-related information was only available to other staff on a need-to-know basis. Further guidelines and protocols were developed over time.

Mark Whiteford, a former service user trainee, is now a project worker at Thames Reach's Robertson Street hostel

Providing support to service user employees

After a period of experimentation and learning, we devised the Protocol for Providing Support Services to Service User Employees. This outlines the framework within which a person can both receive and provide a service.

The principle underlying the protocol is that there should be clear boundaries drawn between supporting and managing people who are both service users and employees. This is clarified in a number of ways, including:

The protocol states that it is not acceptable to contact the service user via the organisation’s employment structures unless given express consent by the service user to do so
Information on employees kept on our client database, LINK, is to be anonymised to protect employees’ confidentiality

This was further developed into a separate procedure on anonymising client records.

Our Protocol for Providing Support Services to Service User Employeescan be downloaded from the policies page.

Anonymised files

During the first 24 months of the GROW traineeships, two issues arose regarding having anonymised data for Thames Reach’s service users who have become employees:

When service user employee details are anonymised on our client database, LINK, it has been difficult at times to quickly locate the duplicate record that contains the real details. One consequence of this is that if a third party, e.g. social services or a hospital A&E, contacted Thames Reach to enquire whether we worked with an individual, there was no way of responding effectively unless the team manager or the keyworker were available.
There were also safety issues to consider. Tenancy sustainment workers visit service users in their homes alone. Thames Reach has a lone working policy and a duty system which would be used in emergencies. This relies on correct name and address details for all our clients being available, so that assistance can be directed to workers when needed or workers’ movements can be tracked if they do not call in. Having no correct details for service user employees potentially puts workers visiting them at risk.

Solutions

To overcome these issues the procedure was changed so that service user employees’ LINK records remain under their own name but only contain a note that the records have been anonymised and to contact the team manager.

This allows someone responding to an emergency call to give the caller the basic information (i.e. that the person is a Thames Reach service user), while all their other information is kept confidential within the duplicate anonymised LINK record.

It has also been agreed that when workers visit service user employees at home, their correct name and address are recorded on the whiteboard in the office.

Our procedure for anonymising client records can be downloaded from the policies page.

Lessons learnt

In summary, over time Thames Reach has had to adapt and we are not able to provide our service users who are also employees with complete anonymity. When surveyed, we identified that 7 out of 8 of our service user employees had already disclosed to other colleagues that they had been or were service users of Thames Reach.

So although at the start of GROW there was a strong feeling within the Service Users at Work Group that protecting service users’ anonymity was paramount, the slight loosening of this protocol was compatible with the behaviour of the service user employees themselves.

Finally, there appeared to be confusion amongst workers about how to discuss service user employees’ support issues within the team, i.e., whether anonymised details should be used. Therefore, each service user employee signs an agreement when they started work which stated clearly how the support team would record, store, share and discuss information related to their support.

This should make clear to both the service user employee and the support worker how to manage their confidential information.

Lesson learnt

The support agreement

When a trainee placement broke down and the service user employee required support services, we learnt that there was often some confusion about who should provide support, and how this should occur. Should, for instance, the placement supervisor contact a support team directly?

To address this ‘grey area’, Thames Reach developed a ‘support agreement’ between the service user employee and the support team. This outlines the procedure and line of communications that should be followed then providing a service user employee with support from the organisation.

If a placement breaks down, the placement supervisor should contact the learning and development manager within the human resources team, who will act as an intermediary, linking the service user employee with a key worker in a support team who will lead on providing support. This system gives everyone involved clear boundaries between management and support.

Lesson learnt

Too many hats

When another trainee wasn’t handling the placement we were not sure how to best provide support. We tried, unsuccessfully, to offer support via other service user employees who were working as project workers.

These individuals were friends who often spent time socialising together. While this seemed like a positive aspect to the relationship, it meant that support meetings were often viewed by the service user as informal. Personal and professional relationships were becoming muddled.

The key worker was asked to go ‘off the record’ about information that was being passed on. Although the key worker in this instance handled the matter professionally, and spoke to their supervisor about the issue, this system was problematic and confusing for both parties.

We decided that we were asking the key worker to ‘wear too many hats’ and have subsequently agreed that a key worker who does not know the service user employee should provide support in these circumstances.