- Home
- /
- By your needs
- /
- Prepare your data
Before analysing, the data have to be in good shape.
Not all data arrive ready to work with. This is the stretch before the analysis: leaving databases clean and usable, protecting them when they contain sensitive information, generating synthetic data when the real data cannot be moved, and leaving a trail of where they have been.
An analysis is only as good as the data that feed it. A database with duplicates, inconsistent categories or dates in three different formats does not give a bad result: it gives a result that looks good and is not. And when those data contain patient information, preparation is no longer just a technical matter: you need to be able to work with them while reducing the risk of exposure or re-identification.
That earlier work, which is almost never seen but shapes everything else, usually responds to four needs that arise before the analysis begins: that the data are clean and usable, that sensitive information is protected, that it is possible to work with synthetic data when the real data cannot leave the secure environment, and that there is a traceable record of who has had access to what.
These are not four versions of the same thing. Cleaning a database and anonymising it are different jobs, and neither is legal compliance advice: it is the statistical and methodological work that makes the data usable under defined technical controls. You can start with the need you recognise as yours.
This is for you if…
You have a database that is not ready for analysis (duplicates, badly coded variables, inconsistent formats, values that don't add up) and you need to get it into shape before working with it.
You work with patient data and need to anonymise them in a way that keeps them useful for analysis, reducing the risk of re-identification to a level appropriate for the intended use, without unnecessarily losing analytical utility.
You cannot take the real data out of their secure environment, but you need a synthetic version that reproduces the statistical properties relevant to the intended use, so that you can develop or share the analysis.
You handle sensitive information and need traceability: keeping a record of where the data go and making it easier to identify the source of a copy if unauthorised use or dissemination is detected.
How we can help
Not sure which of these fits your situation?
Tell us what stage you are at and we will tell you what work is needed, or whether none is. No commitment, and to the point.
Let's talk about your dataHow we have approached it in other projects
Before you take the step
How do I know whether my database is really ready for analysis, or whether it needs preliminary work?
You find out by reviewing it: a database looks ready more often than it actually is, and the preliminary work consists precisely of checking this before analysing. This applies when you have collected data and are not sure whether you can go straight to the analysis or whether the data carry issues that would compromise it. The usual signs that preparation is needed are duplicates, badly coded variables, inconsistent categories, dates in several formats or values that don't add up. The risk of skipping this step is concrete: a database with these defects does not give an obviously bad result; it gives one that looks good and is not. You don't need to identify the issues yourself; an initial review determines what the database needs before work on it begins.
Cleaning a database, anonymising it, generating synthetic data… is it all the same thing, or are they different jobs?
They are four different jobs that respond to four different needs in the stretch before the analysis. They get confused because they all happen "before analysing", but they are not interchangeable: leaving a database clean and usable is one job; reducing the re-identification risk of sensitive data is another; generating a synthetic version when the real data cannot be moved is a third; and keeping a traceable record of where the data go is a fourth. A project may need one, several or all four, and not in the same order. Confusing them leads to asking for what is not needed, or to assuming that one includes another: anonymising does not clean, and cleaning does not protect. The first thing is to identify which of the four needs is yours, or which ones, so that you neither commission more than you need nor fall short.
I work with patient data. Is this legal advice on GDPR compliance?
No: this is statistical and methodological work on the data, not legal advice on regulatory compliance. The distinction is deliberate and is not blurred. It arises when you handle sensitive information and need to be able to work with it while reducing the risk of exposure, but what you are looking for is the technical side, not a legal opinion. What we do: reduce the risk of re-identification in a controlled way while preserving analytical utility, generate synthetic data when the real data cannot leave the secure environment, and apply traceability techniques to the copies. What we do not do: issue a judgement on GDPR compliance or replace the legal advice that is the role of legal advisers. The boundary is clear: the methodological work that makes the data usable under defined technical controls, yes; the legal validity of that processing, no.
If I anonymise my data, do I lose analytical capacity? And do synthetic data increase my sample?
Anonymising has a cost in utility that is managed, and synthetic data neither increase the sample nor create new information: these are two limits worth being clear about before deciding. On the first point: protecting data reduces their analytical utility to some extent (data that are anonymised too heavily stop being useful for analysis), so the work seeks the balance between protection and utility that suits the intended use, not maximum protection applied blindly. On the second: a synthetic population reproduces certain distributions and relationships of the original and is useful for developing processes, sharing structures or simulating scenarios, but it neither replaces the evidence contained in the real sample nor extends it. Mistaking synthetic data for new data leads to conclusions that the real sample does not support. The decision is made with those assumptions and limits explicit, not on a promise of total protection.
My database is already prepared or protected. What is the next step?
The natural next step is to analyse it: preparing and protecting the data is what makes the analysis possible, not an end in itself. This arises when the preliminary work has left the database clean, protected or synthesised and ready to work with, and the question becomes what to do with it. From there, the right place to go is **I have data and don't know where to start**, where the analysis that answers your question is chosen according to the nature of the data. Preparation and analysis follow on from each other naturally: one gets the data into shape, the other turns them into knowledge. You don't need to finish the preparation completely before starting to think about the analysis; they often overlap, and that way the subsequent analysis holds up instead of carrying over defects that would invalidate it.
Can we start with an audit of the database before deciding what work it needs?
Yes, and it is often the most sensible way to start: an initial audit makes it possible to decide what work the database really needs, instead of committing in advance to a full cleaning, anonymisation or synthesis. This arises when it is not clear what state the data are in, or which of the four needs (cleaning, protection, synthesis, traceability) is the relevant one. The review assesses the structural quality of the database, how sensitive the information is and which technical controls it requires for the intended use, and the real work is scoped from there. That guards against two pitfalls: paying for treatment the database does not need, or falling short on the treatment it does need. The result is a diagnosis and a tailored proposal of what preparation or protection the database needs, before committing to the full scope.
Preparing and protecting the data is what makes the analysis possible, not an end in itself. Once the database is clean, protected or synthesised and ready to work with, the natural next step is to analyse it: see how we can help if you already have the data and don't know where to start. If you are still weighing up what your database needs first, let's talk.
Shall we talk?
Tell us what you are working on and we will give you a straight answer on how we can help.