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. |
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:
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:
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:
Important notes
A note of caution about approaches to matching:
|
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.