Equal Code: re-inventing the training wheels [Part One]

A watercolour of circles and lines spread out randomly. Each are vivid colours.
An AI models social care training data

This is part one in a new series where we're looking at our difficulties with contributing to the national Adult Social Care Workforce Data Set (ASC-WDS). Along the way, we're going to build ourselves a real replacement system that patches over the missing functionality that we need.

Training is key to great care

As anyone who's worked in a role that provides a personal service to another person knows, providing care and support to someone is an enormously varied task. During a single session, you might have to pull on threads from your childhood, your own lived experience, advice from colleagues, previous interactions with the individual, professional training or specific medical training (to name a few!)

Keeping up with training, especially when it's related to health and social care provisioning, is a constant requirement for nearly all of our workers. Not only is it a regulatory requirement for us, it's general best practice and helps people to feel confident in their own abilities.

Skills for Care

Skills for Care is an independent charity, backed by the government at both national and local levels, that aims to make sure people have all the training they need to provide excellent care. Their vision statement is:

we all want to live in the place we call home with the people and things that we love, in communities where we look out for one another, doing the things that matter to us

I doubt any of us would argue with that, but it doesn't tell us much about how they go about doing that. Our interaction with them is through the catchily-named Adult Social Care Workforce Data Set (ASC-WDS). The ASC-WDS is a tool that enables the Government, the Department of Health and Social Care, local authorities, and the Care Quality Commission to monitor the skills on offer by carers at each Care Provider and use that to inform their plans for each area. In Calderdale, when we do work through the Local Authority Frameworks, we're required to further this vision by contributing to the ASC-WDS.

Sharing data in this way is an excellent goal, and we're 100% behind the idea that creating open, comprehensive data sets opens up opportunities for better decisions. We're not only required to contribute to this data set, we want to.

Current landscape

In order to contribute, you have to enter information into the online service offered by Skills for Care. Our experience with this has been difficult; really difficult.

It's worth saying up-front that our desired way to interact with the ASC-WDS is not typical for the type of provider that is incumbent in our sector. Although this article is full of criticism, we think that the tool is a great start and applies well to a lot of use cases.

The gov.uk open standards principles are transforming what's possible across the public sector, but they require each tool to adhere to the standards reliably and predictably. This must be true for the general public as consumers of the data, but also for the organisations contributing that data. Skills for Care provides a decent website that makes it possible to describe your workplace, the services you offer, the people that work for you, and their training. You can individually edit each of the records.

Unfortunately, updating our data on the ASC-WDS by hand, using the website, is not an option for us. It would simply take far too long for the number of staff that we have. Our co-op is about working smarter, not harder, and we lean on technology to help us when it's appropriate. Luckily for us, there is a way to bulk-upload data to the site. Unluckily for us, the format of those CSVs is very difficult to work with.

Bulk uploads

Creating a CSV to interact with the bulk upload feature of the ASC-WDS comes with three separate PDFs that offer guidance about how to construct the CSV. Before we continue, I would encourage you to at least skim them:

My goal, as the person who is designing the way that Equal Care can interact with the ASC-WDS, is to match our understanding of "how training works", with the understanding presented by this guidance. Once they're matched up, I can create a way for us to translate between the two.

The ACS-WDS data model

Understanding the Skills for Care data model isn't the easiest task when all you have to go off is the guidance PDFs, but here's where we're up to so far.

Here are some of the difficulties when understanding how to create these CSVs:

  • In the guidance intro, it states "any data that does not follow the specific rules will be ignored". This instantly ups the stakes. Whilst there is validation in place, it's clear that we can't rely on it to catch everything (otherwise this piece of advice wouldn't be necessary).
  • The intro also states "You must upload both workplace (was organisation) file and staff records (was worker) file together otherwise you will not be able to validate your files." Further evidence that validation isn't applied rigorously and shouldn't be trusted.
  • The icing on the validation cake: "If [the training file] is not included within your bulk upload it will be assumed that any data already held for training will be deleted." We best not be making any mistakes then...
  • Inconsistent IDs. Some ID fields used to uniquely identify a piece of data have names like LOCALESTID,  some CODE. Some things have "id" in the name, but aren't used for a uniquely identifying ID. This makes it difficult to guess what something is for and requires you to make more mental hops when trying to understand something.
  • Array fields. There are lots of fields that represent a list of things, each separated by a semicolon. You must keep all of the fields' lists in sync with each other or they might become nonsensical be rejected, or worse, provide unrepresentative data. Sometimes, there are extra, unique, rules about how to format the fields under certain circumstances.
  • Non-array fields. Qualifications are represented by a dynamic number of fields called QUALACH01, QUALACH02 etc. They serve the same purpose as the array fields but act differently.
  • In many fields, there are numbers that represent options. In nearly all cases, the numbers have gaps. For example, you might be able to choose 1, 2, 3 and 5 but not 4. In other fields, a number is used to indicate a yes or a no. The number for "no" is always 0, but the number for "yes" changes.
  • When there are lots of options for a field, the options are presented in a table. Pulling this table of options out of a PDF is not straightforward.

The problems above don't fundamentally change our approach to dealing with the data. In most cases, we just need to be careful. However, a couple of fields can make all the difference and are worth highlighting.

Change status fields

"Change status fields" is a name (that we've invented) to describe a number of fields that exist across the different types of data. They are:

  • for workplaces: STATUS
  • for staff: STATUS and CHGUNIQUEWRKID
  • for training: there are none.

Depending on what these fields are set as, the operation of the CSV will change. Let's look at a few examples:

  1. If a workplace record has STATUS = NOCHANGE, then the rest of the data is not required but will be counted as updated by the system.
  2. If a workplace record has STATUS = UNCHECKED, then the rest of the data is not required and will not be counted as updated by the system.
  3. If a workplace record has STATUS = UPDATE, then all of the supplied data will overwrite any data already in the system.
  4. If a staff record has CHGUNIQUEWRKID, then the whole CSV should only consist of LOCALESTID, UNIQUEWORKERID and CHGUNIQUEWRKID. The values of CHGUNIQUEWRKID will change UNIQUEWORKERID for each row included. Don't include any rows that shouldn't change.
  5. If a staff record has STATUS = NOCHANGE, then the rest of the data is not required but will be counted as updated by the system.
If this is getting a little confusing, that's because it is!

These fields mean that we have to design a system that can track changes over time; a more complicated option than just tracking the latest version of something.

Where next?

Now that we've got a good enough view of how the ASC-WDS system understands training, we can start to build our version of things. The following posts in this series will be about our journey to building that. If that sounds interesting, you can subscribe to this blog in a couple of clicks below.