Privacy policy

Last updated: 15 September 2026

With this policy, Bielefeld University informs you in accordance with Articles 13 and 14 of the General Data Protection Regulation (GDPR) about which personal data the VirtualSP application processes, for what purpose, on which legal basis, for how long, and which rights you have. The terms “personal data”, “processing”, “controller” and “processor” are used as defined in Article 4 GDPR.

It applies to the application you use after signing in, including its sign-in page and the preview environment. The public website virtualsp.de has its own privacy policy.

1. Controller

The controller within the meaning of the GDPR is Bielefeld University, a public-law corporation with legal capacity maintained by the State of North Rhine-Westphalia, represented by its Rector.

Universität Bielefeld
Universitätsstraße 25
33615 Bielefeld, Germany
Phone: +49 521 106-00
E-mail: post@uni-bielefeld.de

Responsible unit

Medical School OWL, Simulation and Communication Lab (SCoLa)
Dr. med. Anja Bittner
E-mail: anja.bittner@uni-bielefeld.de
Phone: +49 521 106-67420

Data protection officer

Data Protection Officer of Bielefeld University
By post via the university address
Phone: +49 521 106-5225
E-mail: datenschutzbeauftragte@uni-bielefeld.de

2. Principles

VirtualSP is a practice environment of the Medical School OWL for clinical communication. Personal data is processed to provide this service for teaching and study and to develop it further. Unless stated otherwise below, the legal basis is Article 6 (1) (e) GDPR in conjunction with Section 3 (1) of the North Rhine-Westphalia Data Protection Act (DSG NRW) and Section 3 of the North Rhine-Westphalia Higher Education Act (HG NRW). For university employees, Section 18 DSG NRW applies in addition.

The application uses no analytics, tracking or advertising services, loads no third-party content and makes no automated decisions within the meaning of Article 22 GDPR. No profiling takes place. Data is passed on only to the service providers named in section 7, and only as described there.

3. Accessing the application

Access data

Each time the application is accessed, the server necessarily processes connection data: the IP address of your device, date and time, the address requested, the amount of data transferred, the status code of the response and your browser identifier (user agent). This information is stored in the server’s system log and serves operational security, troubleshooting and the defence against attacks. It is not linked to your account and is deleted after 14 days at the latest.

To protect against overload, the server counts requests per IP address in memory for one minute; nothing of this is stored. Failed sign-in attempts are counted per account, not per address (see section 4).

Cookie and local storage

The application sets a single cookie: the session cookie “__Host-vsp_session”. It contains a random string by which the server recognises your sign-in, is protected against access by scripts, is only transmitted encrypted and expires twelve hours after sign-in at the latest, or when you sign out. In addition, your browser remembers your choice of language (“vsp-locale”) and colour scheme (“vsp-theme”) in local storage. These entries never leave your device.

Both are strictly necessary to provide the function you requested (Section 25 (2) no. 2 of the German Telecommunications Digital Services Data Protection Act, TDDDG); no consent is required, which is why there is no cookie banner.

4. Account, sign-in and session

Accounts for teachers, research, testers and administration are created by the administration of the respective institution (“local accounts”). There is no self-registration. Sign-in for students via their university’s own sign-in service is prepared but not yet enabled; this policy will be updated beforehand.

Invitation

The administration enters the e-mail address, display name and roles of the person to be invited. The person receives an e-mail with a link that is valid for 14 days and can be used exactly once; through it they set their password. The server stores only a hash of the link. It also records who issued the invitation, when it was accepted or withdrawn, and in which language the e-mail was sent.

Account data

  • sign-in address (e-mail) and display name;
  • roles per institution and, if assigned, the platform administration attribute;
  • an identifier (alias) under which the person is recorded towards AI services and in evaluations; it is assigned when the account is created;
  • the self-chosen name used in conversations — first name, last name and the form of address the simulated person uses. No conversation starts without it; the form of address is not a statement about the person but about how they wish to be addressed;
  • the password solely as a hash (Argon2id), never in plain text, with the time of its last change;
  • optionally a second factor: the secret for the authenticator app stored encrypted, the recovery codes only as hashes, each marked as used or unused;
  • the number of failed sign-in attempts and any temporary lock (15 minutes after five failed attempts);
  • for testers, a quota of training minutes.

Forgotten password

On request, the application sends a link for setting a new password to the sign-in address. It is valid for one hour and can be used once; only its hash is stored. The response to the request is always the same, regardless of whether an account exists for the address.

Sessions

After sign-in, the server keeps a session: a hash of the session token, the institution you are signed in to, the time of sign-in and of the last activity, the expiry time, and a shortened identifier of your browser so that you can tell your sessions apart in the settings. The IP address is deliberately not stored in the session. A session ends when you sign out, after twelve hours at the latest, or when you end it in the settings. If an account’s access is revoked, all of its sessions end immediately.

Purpose, legal basis, retention

This data is required to give you personal access, to determine your role and to protect the account against misuse. The legal basis is Article 6 (1) (e) GDPR in conjunction with Section 3 DSG NRW and Section 3 HG NRW, and for employees additionally Section 18 DSG NRW. Without a sign-in address and password, no access can exist. Account data is kept for as long as the access exists. Revoked access remains visible as “revoked” in the institution’s access management; the account is deleted as soon as it is no longer needed for teaching and administration, at the latest under the deletion policy that becomes binding when regular operation begins. Sessions, invitations, password links and second-factor data are deleted together with the account.

5. Log of security-relevant events

Security-relevant and administrative events are recorded in an append-only log: successful and failed sign-ins, locks, sign-outs, ending of sessions, invitations and their renewal, withdrawal and acceptance, assignment and removal of roles, revocation of access, changes to the platform administration attribute and to quotas, and requests for password links. An entry names the event, the time, the acting person and, where applicable, the affected person and the institution; for invitations, also the invited address and the roles. Passwords, links, codes and IP addresses are never logged.

The log serves the traceability of administrative decisions and the security of processing (Article 32 GDPR); the legal basis is Article 6 (1) (e) GDPR in conjunction with Section 3 DSG NRW. It is accessible only to the platform administration. When an account is deleted, the reference to the person is removed from the log; the entry itself remains. A maximum retention period will be set in the deletion policy.

6. Courses, trial conversations and conversation lab

Courses

Teachers create courses. For a course, the application stores the title, description, term, state (draft, running, ended), the course code in encrypted form, the person who created the course, and the times of creation, publication and end. When a person joins a course, the membership is stored with the time of joining. Courses are visible to all teachers and the administration of the same institution; a course membership is visible to the teachers of that course. Course data is kept for as long as the course is needed for teaching and evaluation; ended courses are archived and deleted under the deletion policy.

Conversation lab

The conversation lab is available to the administration only. It serves to test the language model, the voices and the direction of the simulated person before training sessions are enabled for students. Its use is voluntary. Whoever starts a conversation grants microphone access in the browser; the voice is transmitted from the browser to OpenAI over a direct, encrypted connection (WebRTC), where the language model listens and responds. Our server receives the transcript of the conversation and events about its course over a second connection, in order to direct the simulated person and to display the conversation.

Our server keeps transcript and events in memory only while the session is running and discards them one minute after it ends. They are not stored in the database. The server log records the course of a lab session (start, end, delegations, errors), but no spoken content. The audio is not recorded, neither by us nor by OpenAI (see section 7). OpenAI receives your voice, the transcript generated from it, the role script of the simulated person and the direction’s instructions; your name, sign-in address, identifier and institution are not transmitted. Whatever you say about yourself during the conversation is transmitted, however; therefore do not mention real people or your own health data in the lab.

The legal basis is Article 6 (1) (e) GDPR in conjunction with Section 3 HG NRW (development of a teaching service); you grant microphone access in your browser anew for each session and can withdraw it at any time.

Trial conversations

Teachers and invited test users can try out a scenario in conversation with the simulated person under Teaching → Try out. This is not a training session and is not assessed. Before every trial conversation, the application presents a text about what happens during it; no conversation starts without confirmation. We store your confirmation with context, document, version and time, record it in the log (section 5) and keep with the conversation which confirmation it belongs to. Where optional consents are offered alongside, we also store it when you decline them.

The data flow is the same as in the conversation lab: your voice goes directly from the browser to OpenAI; our server receives the transcript in memory only and does not store it; the audio is not recorded. For each trial conversation we store a record: the scenario with title and version, the session identifier at the provider, start, end, the seconds charged and the reason the conversation ended — no transcript, no audio. Each account has an allowance of conversation minutes; usage is counted from this record. The record is visible to the administration of the institution; it is kept after access is withdrawn and deleted under the deletion policy. The legal basis is Article 6 (1) (e) GDPR in conjunction with Section 3 HG NRW (trial of a teaching service).

Scenario catalogue

Our server fetches scenarios from the sp-szenarien.de catalogue. No user data is transmitted in the process; the cases themselves are fictional and contain no data of real persons.

7. Service providers and recipients

Hosting

The application runs on a virtual machine of IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany, in the Berlin data centre. The database is reachable only from the machine itself; all external connections are encrypted. A backup of the database is made daily and kept for seven days. A data processing agreement under Article 28 GDPR is in place with IONOS. Until the move to Bielefeld University’s IT infrastructure, no student data is processed on this machine.

E-mail delivery

The application sends invitations and password links via AhaSend B.V., Willem Fenengastraat 16, 1096 BN Amsterdam, Netherlands, on infrastructure within the European Union. The recipient address, name, subject and content of the e-mail are transmitted. Open and click tracking are disabled. On our server, the content of an e-mail is deleted after sending; the recipient, subject, template and the delivery status reported by AhaSend are retained. A data processing agreement under Article 28 GDPR is in place with AhaSend.

Language model (conversation lab only)

For the conversation lab we use the OpenAI API; the contracting party for customers in the European Economic Area is OpenAI Ireland Ltd., 1st Floor, The Liffey Trust Centre, 117–126 Sheriff Street Upper, Dublin 1, D01 YC43, Ireland. Processing takes place on servers in the United States, i.e. in a third country for which no adequacy decision of the European Commission covers this provider. The transfer is based on OpenAI’s data processing addendum including the European Commission’s standard contractual clauses (Article 46 (2) (c) GDPR); you can obtain a copy from the responsible unit named above. Please note that access to the data by public authorities in the United States cannot be ruled out and that you do not have the same legal remedies there as in the European Union.

Lab sessions are not stored at OpenAI (setting “store: false”); there is no recording and no retrievable session there. According to OpenAI, API inputs and outputs are retained for up to 30 days for abuse monitoring and are not used to train models. We do not transmit names, identifiers or contact details to OpenAI.

Recipients within the application

The administration of your institution sees your sign-in address, display name, roles, the state of your access, whether a second factor is set up, and the time of your last sign-in. Teachers see the courses of their institution. The platform administration at Bielefeld University sees this information for all institutions. Data is not disclosed to any other third parties unless we are legally obliged to do so.

8. Your rights

Towards Bielefeld University you have the right of access to the data stored about you (Article 15 GDPR), to rectification (Article 16), to erasure (Article 17), to restriction of processing (Article 18) and to data portability (Article 20). Where processing is based on Article 6 (1) (e) GDPR, you may object to it at any time on grounds relating to your particular situation (Article 21 GDPR). You may withdraw any consent given at any time with effect for the future (Article 7 (3) GDPR). To do so, contact the responsible unit or the data protection officer (section 1).

You also have the right to lodge a complaint with a supervisory authority (Article 77 GDPR). The authority responsible for Bielefeld University is:

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen
(State Commissioner for Data Protection and Freedom of Information North Rhine-Westphalia)
Kavalleriestraße 2–4
40213 Düsseldorf, Germany
Phone: +49 211 38424-0
E-mail: poststelle@ldi.nrw.de
Web: www.ldi.nrw.de

9. Changes to this policy

This policy describes the state of the application as of the date given above. When new functions that process personal data are added, such as training sessions for students, sign-in via the university or recordings of conversations, this policy will be updated before they are enabled. The current version is always available at this place in the application.