Simpli San

Authentication

Our authentication implementation uses Keycloak (https://www.keycloak.org/) server. Keycloak is self-hosted so we have full control over the information, traffic and users who login, to control and manage the users. Passwords are encrypted with PBKDF2 (https://www.keycloak.org/docs/latest/server_admin/index.html#password-policy-types) algorithm. Further implementation and how Keycloak works can be read on the link above.

There is only one way how application users can authenticate and trigger the authorisation process. Login form consists of username and password fields. This data is sent to our backend server via POST request. The login endpoint is excluded from the logging pipeline, so this means that users authentication information (username and password) is never stored (only on Keycloak with above encryption). The backend server processes the request and passes forward the credentials to the Keycloak server that does the authorization. The Keycloak server can deny access if the user does not input the correct data or approve it. In this case an access token is sent back to the backend service and from there to the user. More about Keycloak tokens can be read at https://www.keycloak.org/docs/latest/server_admin/index.html. The retrieved token gives the user the right to access certain endpoints, based on their permissions (more information about this can be found in the chapter Roles and Permissions). When the token expires, the user needs to login again.

Authorization of User Accounts

A unique sub-domain has been prepared as well as an admin user for each of the clients (e.g. for you). Company domain is in the form https://company.simpli-san.de. To add employees and assign them to the correct groups you may use the admin user. Users do not have an option to register by themselves. They have to be added by a different user with the correct permissions for this action. The matrix of the groups being assigned to the specific user is completely controlled by you. If a user is assigned to the Admin group, then the user is given the same rights as the initial user; this enables you to have more than one admin user for redundancy reasons.

Password and User Data

By default, password strength policy is limited to require a minimum of 8 characters for a password. However, upon request we are able to set additional password strength rules for each client separately to follow the policies of each individual client company.

Users can change their personal data when they are logged in the system (first name, last name, e-mail, phone number and password). Having the right permission, a user can have an option to change the password for other users. Again, the possibility or prevention of this functionality is definable upon request of the client.

If a user forgets the password, they should notify the superior officer who has the right permissions to set a new password for their account. Users might be requested to reset such passwords at first login (definable upon request of the client).

Roles and Permissions

Permissions

Let us first describe our permissions, so the roles could be better understood.

Permissions are implemented in a way of object-based permissions. When a request for checking permissions is made, an object's required permissions area is compared against all of the user’s permissions (later defined/explained). The permissions can be divided into two groups, basic and purpose. The basic permissions are defined for an object and include most of the time the following actions: create, retrieve, update and delete or destroy. For example if a user only wants to see the list of all patients, then they must have the retrieve permissions, but in order to update them, the update type permission is required. The other type of permissions are purpose permissions. Under these permissions we define the permissions with a specific action that can be triggered by users a single or set of objects.

Roles

The implementation of roles in our software is made in a way that only a certain set of users can create roles and assign them permissions. These are called groups. Later, each user can be assigned to one or multiple groups. When the server is checking if a user can perform some action, the union of all permissions (over all groups that the user is assigned to) is made and the required endpoint and request type permission is checked for.

Assigning Permissions and Roles

There are predefined groups that are already available to clients. Predefined groups are prepared to simplify the onboarding process. The client’s user with specific administrative permission (administrative user for the Client) can add, change or remove the permissions from the groups. Administrative users can only remove non-system groups.

Data Protection-compliant Deletion

For storing data that is in use, Google cloud SQL service (https://cloud.google.com/sql) is used to achieve continuity and reliability of data access times and other important features. One of the most important features is backups that are created daily. In case of any major incidents, the backups can be restored. There is a backup retention policy in place.

The DPA has been signed between Simpli-San and Google. Additionally, database storage is located in the EU region. For accessing the database, a special username and password are used that is never transmitted over network traffic.

Deletion (which permanently deletes the data) is made by us exclusively on the client’s written request. After the retention period of the backup is reached, the restoration of such data is not possible anymore.

The end users (e.g.: patients, doctors, …) have to request the deletion of their data directly from the client (you) acting as a controller of the data. The client then checks the requirement and requests for the deletion of the data from us as a processor. Additionally, the client is able to request the data deletion that is older than some period of time, regarding the legal basis of the data the client uses for processing personal data within the database.

So far, no client has requested the deletion yet.

Implementation of data subject rights

There is a strict policy in place that we do not export or reveal any data based on direct requests from the data subject (e.g.: patient, doctor, end user). In no case Simpli-San will reveal or export the data directly on the data subject’s request (strict controller-processor policy).

We enable limited functionality to our clients to prepare answers to data-subject requests by themselves. It is nevertheless possible that some of the preparation processes will not match the needs of our client. In such a case, the client is always able to request additional reports from us.

In order to achieve their rights according to article 20 of GDPR, end users (e.g.: patients, doctors, internal users etc.) have to request the copy of their data in a machine-readable form directly from our client which acts as a controller to us. As there is no automated system to export the data yet, the controller is then invited to request the export of the data for the specific data subject from us.

Exported data is provided to the controller in JSON format through a secure channel within our solution.

Ensuring confidentiality, integrity, availability and resilience

Apart from the API, all services mentioned in this document run in a closed environment and are not accessible from external networks. Furthermore, our services do not communicate with any other external services apart from the ones listed in this document.
Access logs are saved upon every request and access to the database. Some of the processes that we implement and offer, have additional logging that can be used in case of mistakes inside the system.
The content of sensitive requests (e.g. passwords, private keys, other credentials, …) is excluded from being logged in system logs. With this we prevent some sensitive data from appearing in later searches. Each action is still logged and can be later found in the logs.
Logs are saved in the elastic search that enables us to make fast queries. To display and search over logs, Kibana is used. Kibana is hosted inside our core system and access is allowed only to authorized personnel.
System runs on Google cloud (https://cloud.google.com/) that is located in Germany.
For availability we use Kubernetes (https://kubernetes.io/) that allows us to have multiple instances of the same system running at the same time. With this we increase the availability and can handle multiple requests at the same time and scale an application based on the current usage.
Systems that are running more complex and time-consuming tasks are running on separate instances of the system (still inside one kubernetes network). With this solution, long running tasks do not affect the API response times.
For additional availability we use load balancers that manage traffic in the Kubernetes network and allow dispersion of the API requests over multiple systems.
Data traffic from our system to the client is SSL encrypted.
Data is stored inside the Google cloud solution, SQL (https://cloud.google.com/sql) database. Access to the database is only possible with a key that is never transmitted over a network.
All of the data in the database (and other storage such as Google bucket) is encrypted (https://cloud.google.com/sql/faq#encryption).
For data loss prevention we have automatic backup running every day.
All of the data and backups are stored in Germany. Upon specific request, we are able to assure additional Client backups to be provided to each Client separately.
System Administrator access is granted to authorized personnel only. Kubernetes management is possible only from our office networks.

Prevention of unauthorised reading, copying, changing or deleting

Unauthorised access to the database (that includes reading, copying, editing and deleting) is prevented by giving proper access rights to the database only to the authorised personnel.
Access logs to the database and to the environment are periodically checked allowing us to detect if there are any unauthorised accesses to the data sources.
Logs are available on the page to enable the client’s administrator to check accesses from the client's users. The logs give us and the Client an option to see if the data was viewed or changed, which user did some action and what was the content of the change.

Prevention of the unauthorised entry of personal data as well as the unauthorised reading, modification and deletion of personal data

The system allows only specific users (groups) to change or add the data of the patients stored in our system.
Administrators of the system assign the permissions to the users that are then able to create, view and edit the patient's information.
Upon API request to create or to edit any of the patient’s data, the system checks the permissions before accessing the database and changing or creating any new entries. Permissions are checked by the Keycloak.
All of the actions (made on permissions and patient data) are recorded in logs that are visible to administrative users (users with proper rights) from inside the solution.

Guarantee that those authorized to use an automated processing system only have access to the personal data covered by their access authorization

Our solution does not have any automated process or profile any of personal data stored in the system.
In case of automatic processes (such as document builders), the Client has the option to decide what information is sent and processed.

Ensuring that it can be checked and determined to which places personal data has been or can be transmitted or made available with the help of data transmission facilities

For all of the data transfers we keep a scheme of network transfers. Occasionally the network transfers/traffic is captured and checked if it is compliant with other system access logs.
External services that are using our system are first required to supply a username and password to get the access token. With this token they are able to make requests based on given user permission groups.
For every access of the external service to our system access logs are being made.
The logs can be later checked by the client or by us.

Guarantee that personal data collected for different purposes can be processed separately

The data that is created, used and managed by the client to support the business logic is owned by the client. We do not do any additional processing of this data or personal data.
The data inserted within our application is being used only to process prescriptions and orders (art. 6(1)(b) of GDPR) and we do not process the data for any other purpose.

Ensuring that it can be subsequently checked and determined which personal data has been entered or changed in automated processing systems at what time and by whom

To ensure this we offer to the users a view of all of the access logs. These logs give all of the information about what data was viewed or changed (personal or business).
Access logs enable us to check what actions were done on some data resource and which actions some user did over some period of time.

We hope that all of your questions were answered. Some of them might have been misunderstood, so we are prepared to arrange a video meeting or to further explain them in a document form like this one.

Aljaž Glavač
aljaz@simpli-san.de