Events

Events can be created and managed in SORMAS.

Events are understood to be signals (information from the public, police or media, for example), screenings (medical series tests), outbreaks with more than one confirmed case (clusters) or various other occurrences (events) that are related to an outbreak. Event participants can be created and associated documents, e.g. lists of participants, can be saved. In addition, document templates can be stored for download, e.g. letters to institutions or schools. Also, location specification as well as superordination and subordination of events are possible so that outbreaks can be specifically assigned and hierarchically structured. People who are connected to the outbreak can be recorded as event participants without necessarily having been in close contact with the infected person. They are not sent to quarantine or traced by phone call but can be converted into a contact person or a case with a single click if required.

List of events

Select Events from the blue ribbon on the left-hand side. This takes you to the event directory.

All events, clusters, signals and screenings that fall under the user's assigned responsibility are displayed in the event directory. You can display the directory according to your requirements using filters (A) or sorting by clicking on table headings. There is also the option to export (B) the data. The filter for the responsible user requires the prior selection of a region in the “region” filter. You can also search for an event by entering the event ID, the event title or the description (C). In addition to the filters for the event start date and the development date, you can also filter by the reporting date of the event. Always select the "Apply filter" field or confirm your selection with ENTER. After the number of days configured, events are automatically archived by the program. You have the option of displaying archived events instead of active events or both, as well as deleted events (D). To open an existing event that is displayed in the table, click on the blue event ID in the first column (E). This will take you directly to the event information, so to speak the file for this event.

Create a new event

At the top right of the event directory you find the "New event" button, which you can use to open the corresponding input window.

All information about this event has to be entered in the input window. The program automatically assigns an event ID and fills in the date of creation as the date of report of the event (A).

The event status (B) can be selected below this:

"Signal" refers to information or indications about e.g. COVID-19. There are different sources of signals, that can be selected from a drop-down menu. Depending on the source type a number of input fields appears, e.g. when the source type is hotline/person, then the name and contact information can be filled in.
A signal includes the date of the report, the source of information, and a description of the signal and the case(s) associated with the signal. For example, a signal could be a reference to a demonstration by COVID-19 deniers.

An "event" is related to e.g. COVID-19. It includes at least one suspected case and can have several contacts or participants. These can be converted into cases if necessary. An event includes the date of report, a description of the event and the localization. Such an event could be, for example, a choir rehearsal or a wedding reception.

"Screening" refers to the collection of samples and testing for e.g. COVID-19 in a defined group of people. Screenings have participants and a localization. Samples and laboratory results can also be assigned to participants. For example, a screening can be created in a care facility.

A "cluster" is defined as the joint occurrence of more than one case that are related to each other (e.g. daycare groups or school classes). Clusters have at least two cases, contacts or participants and a localization. These can also be nosocomial clusters. Contacts and participants can be converted into cases. Clusters are created around a case, but new cases can also be added to an existing cluster. If appropriate, several "regional" clusters can also be expanded into a state or nationwide cluster.

The "dropped" status can be selected (at a later date) if it turns out that the event was not related to e.g. COVID-19 after all or was cancelled. The use of the Event Management Status (C) field can be defined by each organization or country. One possibility would be to use it as an overview of how far you are with checking and processing the event.

The event identification source (D) makes it possible to document whether it is the result of forward tracing or backward tracing.

The epidemiological risk level can be recorded under (E).

The date of event should be noted (G). The event evolution date (H) (or, depending on the status, also "signal evolution date", "cluster evolution date", "screening evolution date") offers the possibility of recording when the event developed into an outbreak worthy of investigation. For example, if a school class with initially one infected pupil was recorded as an event and further positive cases from this school class become known after a few days, the event should be classified as a cluster (you do this manually, it does not happen automatically). The "cluster evolution date" is the date on which you make this change, i.e. as soon as the new cases from this school class become known.

The fields External ID, External token (I) can be used if the health authority decides to do so. In case other systems are connected to SORMAS, and events are transferred to these systems, these fields may automatically be filled.

It is important to specify a specific title (K) for the events, as these can be filtered later in the event directory and the event titles can be searched for specifically. If the title is too general, e.g.: Birthday party, this can make it difficult to identify the correct event when searching. It is best to define a standardized procedure for this. The event can be described in more detail using free text in the description field.

The source of information (L) of the event can be selected. Depending on the selection, different fields appear to specify the source.

Entering the location under type of place (M) enables precise assignment; facilities as well as private addresses, public locations or means of transport (e.g. bus, plane, etc.) can be entered here. When entering addresses, it is also possible to use the geo button (N), which automatically calculates the GPS coordinates and transfers them to the maps in the monitoring and contact overview (dashboard). Addresses of facilities are entered automatically if they have been configured.

You can save your entries as usual at the bottom right.

Add event participants

In the event participants tab, you can enter event participants manually or import entire lists automatically (max. 20 MB per import file). All event participants with information such as name, age, vaccination status, samples taken, etc. appear listed in the table.

To add a person manually, click on the "Add person" button on the right above the list. The input window opens, in which you must enter the type of participation (e.g.: guest etc.) and the first name, surname and gender before clicking on "Save". You can use the magnifying glass symbol to search whether the person you are creating is already stored in the system.

If a person with the same or a similar name already exists, the duplicate detection window opens. Use the date of birth, for example, to check whether it is the same person. If this is the case, select the correct person from the table (A) and save it. If it is not the same person, you can create a new person (B), which is then initially stored as an event participant.

Another window "edit person" appears, in which you can enter personal data such as address, telephone number or e-mail address. Save these entries as well. The person is now included in the list of event participants.

At the end of the event participant tab, you can see the "deletion date" if deletion periods have been configured. This shows when the event participant will be deleted from your SORMAS instance. It is also possible to permanently delete events and event participants. Deleting or closing cases, contacts and events is only possible with the administrator user role. Further information on the deletion processes can be found in the deletion chapter or in the admin manual.

Within an event, under the event participants tab, you can select the people between "active event participants", "archived event participants" or "active and archived event participants" to get a better overview. Also, “deleted event participants” can be filtered.

Mechanisms for recognizing duplicates

This chapter explains the detection of potentially duplicate persons, cases, contacts and events in SORMAS - how the process works in general and which variables are taken into account:

General information

Duplicate detection is always based on the responsibility of the user who creates or imports persons, cases, contacts or event participants into the system. Data that the user does not have access to is not taken into account, meaning that it is theoretically possible for duplicates to be created even if every user makes consistent use of duplicate detection. To remedy this, users with the appropriate rights have access to the special "Merge duplicates" view (for cases and contacts), which is accessible via the respective directories. The system can be cleaned up here by merging duplicate data.

Please note that there is currently no duplicate detection when data is transferred to SORMAS via the ReST interface!

Persons

Whenever a user attempts to create data concerning persons - cases, contacts or event attendees - the system checks for similar persons before a subsequent duplicate detection of the actual case, contact or event attendee is performed. A person is classified as a potential duplicate if it meets the following requirements. Any variable that is not specified for the person created is ignored in this calculation.

⮚ The person must have a similar name.

To recognize similar names, the pg_trgm module of PostgreSQL, which uses trigrams to calculate the similarity between two strings, in this case the names of two people. The default threshold for similarity is 0.65. This threshold can be adjusted by changing the value of the namesimilaritythreshold server property (please contact Netzlink Informationstechnik GmbH). The higher the value, the more similar the names must be for them to be recognized. An exchange of first and last names is recognized; UE/ Ü is recognized for first and last names (e.g. Müller and Mueller); separators are recognized for first and last names.

⮚ Both persons must have the same gender or no gender (if specified for the person created).

⮚ The gender "Unknown" matches any other gender, so the system would recognize a person with the gender "Unknown" as a potential duplicate of a person with the gender "Male", "Female" or "Other" as long as all other requirements are met.

⮚ Both persons must not have a different year, month or day of birth (the date of birth must be identical).

⮚ Persons are also recognized as potential duplicates if their year, month or day of birth is blank. They are only excluded if there is an actual different value.

⮚ Both persons must not have a different national health identifier (not relevant for German systems).

health insurance number, this field is used for duplicate detection. Since version 1.68, the passport number and health insurance number fields are no longer available, so they can only be used to compare duplicates in previous cases if both cases have the fields titled. Otherwise, the fields are not taken into account in a comparison. If you have used this field for other purposes, duplicates will not be recognized as these fields are used for duplicate recognition.

⮚ If available, both persons are stored with the same reinfection date.

A configuration option allows you to activate the following setting, which is deactivated by default: The person must be linked to at least one case, contact or event participant.

If the server property duplicatechecks.excludepersonsonlylinkedtoarchivedentries is activated, the associated case or contact or the event to which the event participant belongs must also be active, i.e. not deleted and not closed.

Participants in events

If a user attempts to create an event participant and a potentially duplicate person has been identified and selected, the system also checks whether there is already an event participant for the selected person in the associated event. If this is the case, an error message is displayed to the user informing him/her of this fact and preventing him/her from creating a duplicate event participant.

Convert event participants to a case or link an existing case to the event

If you would like to generate a case from an event participant, you can do this via the "Case ID" column in the list of event participants. If the person has not already been linked to the event as a case, the entry here is "Create".

Clicking on "Create" in the "Case ID" column opens the input screen for creating a new case (see section 2.1.2). Some information is already pre-filled, taken from the details that were already entered for this person when they were created as an event participant. Fill in the remaining mandatory fields. Then save. If the case or a similar case is already stored in the system, the duplicate recognition function will ask whether this is the same person. You check this (e.g. using the date of birth) and can either confirm the proposed person or create a new case if it is not an existing case in the system.

You will then be taken to the first page of the case file. The link to the event can now be seen on the right-hand side.

If you want to return to the event from here, click on the "pencil icon" of the corresponding event in the "Events" box. This will take you back to the event file.

At the end of the Event tab, you can see the "Deletion date". This shows when the event participant will be deleted from your SORMAS instance. Deleting or closing cases, contacts and events is only possible with the Administrator user role. Further information can be found in the deletion chapter or in the admin manual.

In the Event participants tab, you can now see that the case you have just created is still listed here, but that a case ID is now stored in the "Case ID" column. This means you can already see from this list which person is linked as a case.

Another option for displaying all cases for an event can be found in the first tab Event in the event information or the event file. Here you will find the "View event cases" button.

This field takes you to an automatically filtered view of the case directory, which shows you all cases that are linked to this event.

Convert event participants to contact

Administrators and users with the roles of monitoring manager and contact manager can create contacts from event participants in bulk edit mode. This function can be used after selecting the relevant event participants (for more information on mass editing mode, see the admin manual).

All other users with authorization to edit events can proceed as follows: If you want to record that there was a close contact situation between an event participant and the infected person, you can generate a contact situation for a created event participant at any time so that the person can then be sent to quarantine as a contact and tracked. To do this, click on the person's "Event participant ID" in the participant list (first column).

This will open the information page for this participant, where there are three grey boxes on the right-hand side. Select the "New contact" field in the "Contacts" box.

The input screen for this contact situation appears (see chapter 3.2.1). Select the responsible federal state, district or district-free city and the municipality. Use the blue "Select case" button to link the index case (if already created in the system - if this is not the case, you can use the "Case ID in external system" field to enter a different ID if the case is documented elsewhere) and use the fields below to describe the contact situation (not shown in the screenshot below). By saving, the event participant is converted to a contact and the corresponding contact file opens.

Links in events: Tasks, actions, documents

The Event tab on the right contains numerous linking options: You can link documents, internal tasks, actions (external tasks/notes) as well as event groups and superordinate and subordinate events. The administrator can store letter/document templates for events so that they can be downloaded by employees.

Create tasks for events

If you would like to create a task for yourself or a colleague for an event, you can do this by clicking the "New task" button in the respective open event. Existing tasks that you would like to edit can be opened using the pencil icon (see also chapter 4).

Create actions for events

Actions describe higher-level tasks that must be carried out by external bodies. This means that you at the public health department do not have to take action yourself at first. Enter here, for example, if you are still waiting for participant lists from external bodies (organizers, public order office, etc.). Disinfection campaigns or barrier measures could also be recorded here. In addition, you can upload documents not only for the event itself, but also for the actions, provided an action is stored for an event.

Documents for events

Documents can be uploaded and stored in various formats via the "Store document" button, e.g: Passenger lists. The "Create" button can also be used to select and download office-specific letter templates (handouts etc.), provided they have been saved by the administrator.

Superordinate and subordinate events

Events can be superordinated and subordinated in SORMAS. This allows outbreaks to be sorted and processed by topic or localization or in your outbreak sequence. The function can be used for a wide range of situations; for example, depending on the specifications in your office, you can process outbreaks in facilities, larger households or note groups of the same means of transport such as a flight, a cruise ship, a bus line or different school classes in a school in their respective epidemiological contexts of the infection chain. To do this, click on "Link event" in the respective Parent event or Child event boxes.

Then select an event by searching via the ID, title or description from events already entered in your instance (in this example, we searched for "medical facility") or select "New event" at the bottom left to create one. The link is created by saving.

In this example, a specific outbreak has been linked as a subordinate event or cluster to the superordinate event "Outbreaks in medical facilities". The link can be broken again at any time.

Creation of event groups

In addition to the hierarchy for events, you now have the option of grouping events. Event groups are generally used to manage events, whereas superordinate and subordinate groups represent infection events. In the event, you will find an "Event groups" box on the right under the superordinate and subordinate events. In addition to the Events and Actions tabs, there is now also a Groups tab in the event directory.

Event groups can be created, edited and linked by the administrator, national user, monitoring team, monitoring officer, event officer and community officer. The administrator and the national user may delete event groups and the administrator may close them. As an administrator, you can use the mass editing mode to select corresponding events and assign them to a new or existing group.