Liberating our social care documents

Watch the Show & Tell on our YouTube channel

Even before the COVID-19 pandemic, Hackney had taken steps to move some of our corporate applications outside the firewall, though still requiring a council-managed device. With the urgent move of as many staff as possible to home working, many staff are using personal devices or council-owned Chromebooks which aren’t configured to access corporate apps even outside the firewall. Therefore, for these apps, staff use a virtual desktop service called MyOffice. But with so many people trying to use this service at the same time, it’s not always reliable and can be slow. 

Mosaic is one of our main caseworking applications, which we made available to staff over the internet to reduce pressure on MyOffice. However, it has two document management systems associated with it, Comino and eDocs. Both of these required users to log in using MyOffice; this meant the end-to-end user experience was poor and complex, and there was still an unnecessary load on MyOffice. Our aim was to enable staff access to their documents without having to use MyOffice. 

We put together a team made up of staff from Hackney and developers from MadeTech, who had been engaged to support our move off MyOffice. We identified three areas of work:

  1. Exposing eDocs documents via an API with Google authentication
  2. Adding support for Social Care Comino into the W2 Documents API (and potentially exposing an interface to query it)
  3. Redirecting the user from the URL stored in Mosaic to the correct URL for the document
Season 6 Episode 3 GIF - Find & Share on GIPHY

We established pretty quickly that Comino documents were not heavily used by staff in comparison to eDocs documents – they are mostly legacy documents. We decided that we could leave these documents being accessed via MyOffice; although not exactly an edge case, it was much lower priority than eDocs. 

There was an existing API for eDocs, so we built a simple tool that uses the existing document ID as the input to retrieve the document from the remote server to AWS, and displays the document in the browser. This part of the project was relatively quick and we thought we’d be done in days. 

The last step was to redirect the (internal) URL in Mosaic to the new URL at – and this is where we became unstuck. While we were able to translate the internal URL to the internet URL, we just couldn’t get the systems to connect. On investigation, we discovered that Mosaic codes the URL into the “Display document” button. Buried deep in the system we found a config file that we thought would control that… but no. We needed a Plan C.

We scoured the technical documentation and found the Frameworki API in which we could change the URL in a config file… and it worked! 

We used otherwise lost time to enhance the prototype service so that documents convert to PDF on download, and set up additional monitoring. Preventing automatic download of documents is important, given the potential nature of the content, but at least having the ability to view the document is a game-changer for our staff. 

We’re using the council’s existing Google Single Sign-On service to secure access, and we’ve set up a separate group to restrict access to the right people. If someone tries to open a document that isn’t web-native, they get a friendly error message telling them to use MyOffice for that document. 

Nothing in this system is new; indeed, MadeTech wisely built upon work they had done for the council’s Single View system used by Benefits & Housing Needs. And the work that we have done around authentication has been reused by the council’s I Need Help service. 

Pleasingly, we only found two bugs in testing, and one of them wasn’t really a bug as the system was working as designed. However, we found that if a user edited a document then uploaded it again, the user would be presented with the original document from cache. We had done this deliberately to speed up the process, but decided it would be better to serve up a fresh copy every time, even if it takes a little longer. 

Towards the end of the project we held a retrospective, which was positive. For a team which had never worked together, never mind together remotely, our teamwork and collaboration stood out. We thought that we were truly agile, using the daily stand-up as a daily planning session for that day’s priorities, and we pivoted quickly to find paths around blockers. 

In terms of future work, if we decide to develop this further, we’d probably look to fix the caching issue first so that the API looks to see if there’s a more recent version of a document each time it’s requested. There may also be opportunities to widen the range of documents that can be viewed in a browser. But we’ll be interested in colleagues’ feedback. 

+ posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.