In the first part of our blog, we described which data protection concept has been used in the projects of the Preventive Medicine Foundation of the Board of Trustees for Home Dialysis (KfH Foundation) since 2009. In this part we would like to explain in more detail how the central pseudonymization service works.
In principle, it must be noted that both data-processing and data-storing systems are used at physically different locations. Here we differentiate between the data sources, i.e. standard PC systems for data entry and data display, the central pseudonymization service (a web server) and the application server on which the medical data is stored (another independent server).
The pseudonymization server is upstream of the application server so that the browser can only request patient-related data via the pseudonymization server. HTML forms without patient-related data, on the other hand, are requested directly from the application server in order to achieve the highest possible processing speed of the overall system.
The first pseudonymization takes place in the documenting center using a patient list. A center-specific patient ID (PID) with the patient-identifying data (IDAT) that is unique to the patient to be pseudonymised is stored in this list. This PID, in turn, is documented in the database together with the medical data (MDAT).
Before the data is saved, the browser-based application first generates a random character string, encrypts it using a public key, sends it to the database server and decrypts it using the private key available there.
This character string is now used on the client side to synchronously encrypt the medical data record – a encrypted medical data record (MDATcr) is created for the patient to be saved. This MDATcr – provided with the associated PID – is transmitted to a central pseudonymization server, which – again synchronously – carries out the conversion of the PID to the pseudonym (PSN). MDATcr and PSN are then forwarded to the central database server. This decodes the MDATcr with the help of the previously sent, randomly generated character string and saves the decoded medical data in connection with the PSN.
The presentation of the centrally stored medical data takes place by simply “reversing” the encryption path. When a patient is called up by entering the PID in the browser-based application, the PID is first converted into a PSN by the pseudonymization service. Using this PSN, the medical data is then identified in the central database, compiled, encrypted and sent back to the pseudonymization service, which decrypts the PSN to the PID but not the medical data record. This is only converted into a readable format and displayed locally in the center.
If you would like to find out more about data protection concept B of the TMF, we recommend the following literature:
Dtsch Arztebl 2003; 100: A 2134, 2137 [Heft 33] (http://data.aerzteblatt.org/pdf/100/33/a2134.pdf) <br>Reng, Debold, Specker, Pommerening. Generische Lösungen zum Datenschutz für die Forschungsnetze in der Medizin. ISBN 978-3-939069-04-1
BACK Imprint – Privacy Policy – Terms of Use – Terms and Conditions – Cook
