Planning data exchanges
It is not uncommon for us to have conversations with potential TIs which may vary from world renowned large corporates to an individual from a school with a great idea. We treat both without fear or favour. A common theme, and apologies if this is akin to 'teaching one's grandmother to suck eggs', is that data journey and ensuring the identity of a person through that data flow.
- I have Mr and Mrs Smith in my application and want to import their children from the MIS.
- Pupils register online for our service and we want to pull their data from the MIS.
- We want to match up staff in our shopping site to FMS users.
Regardless of why I want to Match Mr Smith to his children it is essential that I only match him to his own children and not to anyone else's children. I've picked 'Smith' because there are likely to be many parents called 'Smith' in SIMS. Unfortunately in the case of Parents, there is nothing absolute like a National Insurance Number to uniquely identify every instance of 'Smith'. Even matching on address is no guarantee if there was a father and grandfather of the same name; perhaps 1 in a 100 or 1 in a 1000 parent records we might have an issue but is that OK?
You can always argue that these are edge cases and most uncommon but this is not a sufficient defence against a GDPR breach which will happen given a sufficient number of parental records processed. Moreover, knowingly disregarding edge cases would likely aggravate the offence to an impartial judge.
Without a bona fide alternative identifier such as UPN or NI Number, data needs to start life in the MIS and retain the MIS unique identifier through it's journey. This is particularly important for parents.
The problem with UPN is that staff/pupils will not know their UPN (or at least they are not supposed to under ICO guidelines as a blind identifier). The problem with NI number is that it can be used to link people to external systems but its use should really be restricted to HR, Payroll and Tax unless there is a compelling need with an external justification; our shopping site example is unlike to be a sufficient justification. Thus staff and pupils too are best matched uniquely by the external id from the MIS.
The SIMS external ID is unique to that school or establishment. Be warned that training data will have the same GUID for 'Adrian Blacker' (SIMS training data head teacher) in most training systems, thus care is needed when using multiple instances of training data if global uniqueness is needed. We would recommend using 'Organisation ID' + 'External ID' whereby TIs issue a unique external ID (not school number) to each 'school' within their system.
If a person signs up for a service independently of the MIS data, then it is very likely that they cannot be matched back to their records in the MIS without external (manual) confirmation that 'John Smith' is this particular 'John Smith' and i would recommend that this match was recorded and attributable to a real member of staff. To avoid the hassle, simply base the data exchange on initial exports from the MIS.