Creating a professional linkage platform in adult social care
Developing a prototype

Technical considerations


16. Understand the Family Context tool

The Family Context tool has been developed using the Django framework and other Python libraries to offer a secure and easy-to-maintain product. 

When connected to a database and Azure SSO, it can act as a microservice where organisations can control access and send data to it to display to users in a controlled and simple way.

17. Map your current technical environment

We chose to develop the Family Context tool in a way that can be easily containerised. This is to ensure that it can be easily deployed into any desired virtual environment (AWS EC2, Azure VM, etc). Using AWS as an example, we could use an infrastructure like the one in the diagram below.

Important note

The following is a recommended outline and not a fully implemented solution. You will need to ensure that this approach works for your local infrastructure and technical environment.

A flowchart of an IT infrastructure system, showing components like Azure, GitHub Actions, Docker, databases, DNS, and user access. Arrows indicate process flow between services.

In this solution, the app is run in an EC2 or ECS instance behind a load balancer which is connected to the SSL Certificate. Cognito can handle permissions easily when linked to an SSO provider such as Azure. The repository has a sample infrastructure script that could be used as a starting point, but it is provided as is and will likely require changes to secure and deploy the final solution.

18. Build your combined dataset 

The Family Context Tool does not handle matching data for you. Instead, it displays already matched data. 

This means that you need to first decide on a set of data sources that would serve as a good starting point, then match these data sources together and send the result to the tool to serve to users. 

When deciding which data sources to use, pick a diverse set of sources that you have ready access to. In particular, you may want to consider:

  • Where IG agreements are already in place
  • Where IG is already handled by internal systems
  • Sources deemed most useful to your target user groups
  • Data that can provide a breadth of insight about people within the system and the relevant context

If relying on existing agreements, make sure these are checked and allow the data to be used for the purposes as outlined for the Family Context tool.

For this project, Brent already had an established and operationalised data lake (a large, multi-functional means of holding near real-time data from multiple services) that contained matched data from a range of services, whereas Hounslow had to build their combined dataset from scratch. 

19. Involve information security colleagues and adhere to internal policies and procedures

The Family Context tool requires users to have access to personal data from internal systems. There are higher levels of risk associated with transferring and holding this kind of data. 

Your organisation should therefore have strong information security measures in place to ensure the safety of this data and you should involve information security colleagues in the design of the combined dataset to ensure that internal policies and procedures are being adhered to. 

This is especially important as you will likely also be processing partner data and partners will want assurances that the data you are handling is being properly protected. 

20. Use strong matching criteria 

Once you have your data sources, you need to match them together within the internal system you will be using. In order to do this, it is best to settle on a set of matching criteria. 

The following questions provide a useful starting point:

  • Which fields are common between data sets? (commonly used matching data might include NHS Number or National Insurance Number)
  • Which fields are easy to validate?  
  • Can multiple fields be used to improve accuracy? (match multiple fields to make sure a mistake in one value doesn’t cause a false match)

If in doubt, be cautious. Only match when you’re certain that the records match. 

Taking the above points into consideration, the Family Context tool was designed to match using the following fields because these are regularly found within multiple data sets and provide relatively low risk for matching:

  • Last Name
  • First Name
  • Date of Birth    
  • Address 
  • NHS Number
Important notes 

A note of caution about approaches to matching:

  • Addresses tend to be difficult to validate as they can be written in multiple different ways and may contain errors. To reduce the problem with address variability, you could connect to an address gazetteer record, which is commonly held by LAs as a verified list of addresses.
  • Names may be common (e.g. John Smith) and may not represent a single individual. There may also be variations (e.g. Robert vs Bob, Ellie vs Eleanor, Rehana vs Rahana) in different data sets. You could use a separate ‘link table’ to link records with differing values like these together using other more definite fields.
  • ‘Fuzzy matching’ techniques (where data is matched on stipulated fields) should be used with caution and you should back up any match with other fields whenever possible (e.g. matching Date of Birth with NHS Number but only the first letter of the first name). This can be useful in situations where you need one more layer of matching to get the needed results.

21. Agree a policy for data conflicts and inconsistencies 

Due to the need to match multiple data sources together, conflicts between data sources will naturally arise (e.g. a system holds the incorrect NHS Number for a patient or a GP holds an address for a patient that is different to the one held by the housing service)

You should have a clear idea of how to manage these conflicts and whether reporting will be built in to notify data sources of errors or conflicts. You may also want to display to users which source holds which address for an individual if there are inconsistencies, in order to reduce the risk of incorrect information being displayed. 

Any uncertainty needs to be pushed back to data owners to resolve or be treated as a separate record depending on the situation.

22. Agree policies for data retention and displaying information 

You should have a clear understanding of how long data will be displayed within the front end of the Family Context tool

For this prototype, our teams agreed that only current service involvement should be displayed and that historical involvement with services would not be displayed. 

This decision was made because showing historic information would have led to more complex retention policies and approaches to be implemented, which was considered out of scope for the prototype. 

The nature of what data is displayed within the tool, how long it displays for, and how it will be removed from the combined dataset should be agreed by all partners and strictly adhered to. 

23. Deploy the Family Context tool on top of the matched dataset 

Once the application is deployed on the infrastructure and the data is ready to be loaded, please refer to the instructions on the github repository to learn how to load the data into the system.

24. Test the tool with frontline practitioners and iterate 

Finally, the tool should be tested with frontline practitioners and continuously iterated to improve it. Be prepared for requests for additional data sources, highlighting of mismatches and error reporting. A tool like Family Context is never ‘finished’ and should be iterated over time to ensure it is still adding value to practitioners.

Skip to content

Join the LOTI conversation


Sign up for our monthly newsletter to get the latest news and updates