### Data logistics

To enable efficient handling of thousands of tests per day, we implemented a logistics scheme, which is centered at a self-developped web server wioth associated data bank, which acts both as a custom laboratory information management system and as portal to communicate test results to test subjects. To safeguard subjects' privacy, all samples are identified only by the sample tube barcode. Identifying information (subject's name, address, and phone number) is collected but encrypted in a manner that makes this data wholly inaccessible to the project team. (See below for details.)

The logistics concept is best described by following the "life" of a test tube: First, test kits (Figure XX) are packed, comprising standard items (saline bottle and straw), as well as Micronics sample tube with a preprinted barcode. While packing these into a platic bag, this barcode is scanned and transmitted to the server, which assigns a random 12-digit access code and stores the pairing of barcode and access code. The access code is printed, along with instructions, onto a paper slip, which is folded (to keep the access code hidden) and packed into a small plastic bag together with the rest of the kit. We found that a single worker can easily pack XX such test kits in an hour. We produced bags of 50 test kits, which were handed out to entities (e.g., institutes participating in the test), and distributed there.

A participant would take a kit, go to the web page mentioned in the instructions on the paper slip, and find there a short video demonstrating the sampling procedure, as well as a form to register the kit, i.e., associate the access code with their name, address and phone number. These personal information were immediately encrypted by the web server (see below). Furthermore, information on the test is displayed and the user is asked to confirm informed consent.

After registration on the web page, the subject would then take a sample by gargling and deposit the sample tube in a collection receptacle.

When a new batch of samples was received in the lab, these were heat inactivated and then immediately scanned, in order to mark the samples in the data base as received. Similarly, the results of the LAMP analysis were transferred to the server by our custom-built LAMP plata analysis tool (see below). In the same manner, the results of follow-up tests, such as PCR or repeats of LAMP, were recorded as "events" for the sample. The possibility to thus inspect the "history" of a sample was an important feature to troubleshoot any logistics issues.

To obtain their test results, the test subjects would enter their access code again at the web site. We have designed carefully worded result pages for any possible outcome: For example, the page displayed in case of a negative result would warn the reader to nevertheless stay careful, the page for a positive result would advice to quarantine immediately, as well give links to pages with relevant advice by public health authority's, the page for a preliminary positive result asked the reader to quarantine and check the page again in a few hours. Furthermore, laboratory staff had the possibility to store custom messages for specific samples to inform the subject about unusual circumstances, and thus communicate with subjects without breaking anonymity.

Besides allowing subjects to register their kits and query their results, the system also provides laboratory information management system (LIMS) functionality: For each sample tuibe, relevant events are recorded, such as packing of the test kit, reception of the sample in the lab, results of any test, result queries by the users (timestamp only, no IP address or other identifying information stored), or custom notes. Via a web interface (Fig. XX), staff can query all these information. Furthermore, database queries can provide statistics, e.g., on the number of processed samples, the number of unfinished samples, the rate of positive results, etc. Finally, the system provides functionality to distribute costs to participating organisations or department based on number of handed out or returned sample tubes.

### Data encryption

Safeguarding privacy and data protection is of utmost importance when dealing with medical data such as diagnostic test results. Therefore, we consequently used pseudonymization: Within the laboratory work-flow, only the barcode was used to identify a sample, and it was impossible for anybody in the team to access identifying data on the test subject. As the test subjects identify themselves using the access code on the paper slip, the scheme is suitable for completely anonymous operation.

However, German law requires diagnostic laboratories to report positive detection of certain pathogens, including SARS-CoV-2, to the health authorities, to allow for containment and tracing. In order to be able to comply with this requirement, we had to ask subjects to enter their name and contact details before being able to query a result. This information was then immediately encrypted by the server, using the RSA encryption scheme.

In an asymmetric encryption scheme like RSA, encryption is performed using a so-called public key, which can only be used for encryption but not for decryption, and which therefore must not be kept secret. For decryption, the corresponding private key is needed. After creating the key pair, we deposited the public key on the web server for encryption, and handed the private key to the local public health authority, without keeping a copy of the private key available to the testing team. We added a special portal for the health authority's tracing team to our web server, which allowed them to enter a sample barcode, download the encrypted data and encrypt them locally, on their computer, using the supplied private key. Thus, whenever we detected a positive case, we communicated the sample barcode to the health authority office, who would then obtain and decrypt the patient's contact data and contact them to initiate contact tracing and order quarantine.

This use of public-key encryption ensured that the local health authority office could contact positive cases and fulfill their contact tracing obligation, while it was impossible for anybody in the testing team to obtain any identity data on test subjects. The latter was considered important, as the test was offered to employees of the University, who have a legally protected interest to keep their medical data, including a potential Covid-19 infection, private from their employer (the University, which also ran the tests).

### Further privacy measures

In addition to this, a number of organisational methods were taken to ensure privacy: The paper slip with the access code was folded over, making it impossible to obtain somebody else's access code without breaking the test kit's seal. The purpose of having access codes different from barcodes was to ensure that malicious subjects could not query a colleague's test result by reading off their tube barcode. As a further safeguard, we eventually used metal cans with locks as collection receptacles. Finally, it was important to instruct participating departments to offer the test kits for everybody to take rather than handing them out one by one, thus making it impossible for, e.g. a supervisor, to record who took which test kit (thus compromising the voluntary nature of the test). To which extent such precautions are necessary or dispensible in future use of our scheme will, of course, depend on circumstances and applicable law.

### Deployability of the server

While our server was implemented with the requirements of our specific project in mind, we designed it such that it can easily be deployed for any future use. The code is available on GitHub, an open source repository (see Methods) and documented in sufficient detail to allow any IT professional with relevant expertise to set it up for a new project. As statements like the preceding one are notorious to turn out to be untrue in practice, we stress here that this was tested: Another institution (EMBL Heidelberg) desired to copy our testing scheme. Their IT staff was able to set up and successfully run our server software in their IT infrastructure after downloading our code from the public repository, and to even custmize it to their branding, without having to contact us -- thus proving that our code and documentation are of good quality.

The code has easy ways to customize operations: for example, with a single configuration setting, the system can be switched to fully anonymous operation, i.e., the query for name and contact details is skipped. Also, the text for all pages can be easily changed.

-----

## Methods

### Web server and database

To provide the described data logistics functionality, we implemented a web server in Python, using the Django framework. As it is usually done with Django projects, the database uses the PostgrSQL database management system and the Nginx web server software to serve static content. All web content was written using Django's HTML templating system.

All code for the system is available on GitHub: https://github.com/anders-biostat/covid-test-web-site

The system's database architecture is as follows: The core table, "sample", contains records for all test kits, storing the barcode of the tube in the kit, the access code printed on the paper slip, a field to store the rack (plate) the sample was analysed on, and a reference to the "bag". Each record in the "bag" table corresponds to a set of test kits (in our case, an actual plastic bag containing typically 50 kits) and allows to record which organisatio or department the test kit collection was handed out to. One can thus record for each participating institution of department, which bags they received, and thus query how many of the sample tubes handed out were returned to the lab -- an information required if the participating units (distribution points) are billed for the test service. To simplify the latter, these entities are stored in a table "BagRecipients".

The table "Events" stores all timestamped information associated with samples: Event types include assignment of an access code and printing of a test kit paper slip (PRINTED), reception of a sample in the lab (RECEIVED), finishing of a LAMP test (with results: LAMPNEG, LAMPPOS, LAMPWEAKPOS for negative, positive and borderline positive results, LAMPINC and LAMPFAIL for incocnlusive or failed results, LAMPREPEAT if the test needs to be repeated), and events related to follow-up PCR testing (PCRSENT to indicate that the sample has been sent for PCR testing, PCRPOS and PCRNEG, once the PCR result is available). For each of these sample statuses, a specific text page is associated that is shown to the subject when the result is queried. The logic which status leads to whcih page can be easily changed (in file views_public.py), and new event types can be added. As mentioned, lab staff can store a custom message to the subject, to be displayed instead of the standard texts, by associating the message with a MESSAGE event.

The table "Registrations" stores the encrypted personal information (name, address, and contact, i.e., phone number) of the test subjects, along with encryption metadata (finger print of the public key used for encryption, RSA-encrypted symmetric session key, initial value of the symmetric encryptionn session). FOr encryption,