Equal Code: Winning The Race

One of the battles of any startup is competing against the "big fish" in your sector. In this edition of Equal Code, we're going to look at one of the small ways in which our little co-operative outcompetes our much larger competitors.

Social care contracts

Bear with me for a terminology overload... It's important context.

In the UK, Local Authorities have financial jurisdiction over deciding who receives state-funded social care. They are also legally responsible for 'managing the market', ensuring that there is enough diversity and resilience locally to avoid over-reliance on any one provider. In Calderdale, there are multiple Frameworks (a type of contract) that cover different categories of care. When someone receives care through the Framework, it's called a "call-off". These Frameworks are dominated by large agencies that sweep up most of the opportunities. For Calderdale, there is even a "main framework provider" that de facto gets 70% of the call-offs.

When someone believes that they're in need of extra care and support, after a little fighting to get to the front of the queue, a social worker meets with them and decides on an appropriate assessment (in hours of care) to cover the person's needs. They then rely on the Brokerage Team at the Local Authority to advertise a call-off that fulfils those hours to the available providers. Thus begins "The Race".

The Race

"The Race" (unofficial name) is the process by which someone who needs care and support is matched with a set of carers who can provide it. If that sounds like a terrible way to match people for something as delicate as social care; you're right! Nevertheless, The Race goes like this:

1. The Brokerage Team emails everyone on the list of providers with a summary of the assessment
2. Providers make a decision about whether they can commit to providing that level of care and support
3. The Provider emails back the Brokerage Team
4. The first Provider to email back wins The Race
5. Everyone else is out of The Race, without being told that they're out of The Race

Equal Care enters The Race with a huge handicap: people giving and receiving care and support consent to being a member of every team they're a part of. If you think that sounds like something that should be business as usual, that's because it should be. Unfortunately for the social care workers of the UK, it's not the working conditions they're used to. For larger care agencies, the question is "do we have capacity?" rather than "do we have a person that will fit in this team?"

Whilst The Race is the way it is, we have to live with it. Out of all of the steps, we only have immediate control over steps 2 and 3. Our only option for a competitive advantage is being better at step 2 than everyone else.

Consent!

To build a new team, we have to provide carers with all the information that they need to commit to it. To win The Race, we have to do this and collate responses into a resilient team faster than a large agency checks their "capacity/delivered" chart at any given time/location.

To understand why this is difficult, let's take a look at some examples of the summary documents that we're sent from the Brokerage Team.

To start understanding and prioritising contracts quickly, we want to offload as much of the work as possible to a computer. The bad news is, computers don't read Word documents very well. We need a solution that can take the documents we're sent, extract the key information, then send that information to the right people.

Here's where our technical solution comes in. At a high level, it:

1. Downloads the document
2. Parses the document to create a structured representation of the information
3. Sends combinations of parts of the structured information to the most relevant place in our systems
4. Notifies people that new information is available

For steps 1 and 4, we can lean on our existing systems and let Asana do the heavy lifting. The interesting bit is steps 2 and 3.

Parsing the documents

From previous experience, I know that the python docx library is great. That was the overriding selection criteria here for any scripts, alongside the ability to be able to scale the solution as we grow.

"Parse a document" is too large a problem to solve easily. We needed to constrain the problem to be able to tackle it in a reliable way. Thankfully, in a previous conversation with the Brokerage Team, I had already unearthed the fact that these documents come from their own, custom, records software. There are a limited set of choices for most fields, or they're a text box. All of the tables in the examples we had at the time contained two columns, with a key in the first column and it's value in the second.

This is a perfect constraint and means we can start to build up a structure quickly.

Our script looks like this (with a couple of steps omitted):

from docx import Document

details = {}

brokerage_file = download_file()
document = Document(brokerage_file)
for table in document.tables():
  table_header = table.rows[0].cells[0].text

  if "Person Details" in table_header:
    process_person_table(table)
  if "Service Details" in table_header:
    process_service_table(table)
  # etc.

upload_details(details)

Each function that processes the different tables deals with pulling out specific pieces of information that we want and grouping the rest into a catch-all.

It's as simple as that! The key was in finding the right constraint to make our problem something that we could solve and start using in hours rather than days or weeks. As usual, this kind of solution isn't something that clever code solves; it's something that requires a bit of thought and investigation.

Winning the race

We implemented this solution in an afternoon, and it's still running today. It's had a few tweaks since the first version to extract more detailed information, but it's held up really well. We've been able to pick up a good number of call-offs this way and it can only improve from here.

Though this is a tiny part of our organisation, it's an example of the agility we have that enables us to keep pushing the boundaries on what people should expect from their social care provider. Being able to imagine and implement ideas like this in a day makes Equal Care an exciting place to be.

We haven't open sourced the code for this yet, as it would require a little cleaning up to be useful. If anyone is interested in it - we're more than happy to share. Give me a shout at matt@equalcare.coop.