Patients and the visit matrix

Enrolment, patient IDs, visit statuses and windows, the patient card and status.

The Patients section is the visit matrix of the study: a row is a patient, a column is a scheduled visit. From here you enrol patients and open the patient card.

Enrolling a patient

Click Enrol a patient and choose the site, sex, year of birth and enrolment date. Names and contacts are never entered: the patient gets an ID, and the investigator links it to the medical record at the site.

The ID follows the pattern prefix-site-serial number: REGDIA-01-0005 is the fifth patient of site 01 in REG-DIAB-01 (the prefix is the study code without hyphens, six characters at most). If the protocol has its own numbering, open Your own patient ID and type it in.

The enrolment date is day 0: the windows of all scheduled visits are counted from it.

The visit matrix

The list shows 50 patients a page; the search, the site and the “Overdue” and “With queries” filters work on the whole study. In a study of more than 3 000 patients the overdue count is kept for 10 minutes, with “Counted at” and Count again under the filters (see A big study).

Each cell shows the state of a visit:

• green check: every form of the visit has been verified by the monitor (SDV);
• blue dot: every form is complete;
• half circle: the visit is in progress;
• grey dashed frame: the window is open and there is no data yet; below it, the last day of the window;
• red dashed frame: the window has closed and there is no data (overdue);
• month and year: the visit is still ahead.

A red number on a cell is the count of open queries for that visit. The With queries and Overdue filters show only the patients who need attention, and the search finds a patient by ID. Investigators and monitors see only the patients of their own sites.

The matrix takes the whole width of the screen: a wide monitor or a zoomed-out browser shows more visits. The patient ID and status are fixed on the left and stay in place while the visits move; on a phone only the ID is fixed. Above the table you see which visits are in view (“Visits 3–9 of 12”), and the arrows move the table by a screen of visits; a shade at the right edge shows there are more visits to the right. On a computer the row of visit names stays on top and the scrollbar stays at the bottom of the screen. The Compact button narrows the visit columns: the visit names read upwards, a visit ahead shows as “10.26”, and the captions “by 20.10” and “overdue” show in the tip on hover. The browser remembers the view you chose.

When the study sets a data entry deadline, the filter Late entry appears next to them: the patients with a visit not entered within the deadline (see Data entry deadline and letters to the sites).

The patient card

The card starts with the patient timeline: a lane per visit or event, the window as a bar, the actual date as a dot and today as a red line. Below it come every visit with its window and forms, the patient's open queries and, if the study has patient questionnaires, the patient's personal link (see Patient questionnaires (ePRO)).

Give the date under a visit records the day it actually took place; a date outside the window is marked. If the visit did not happen, choose Did not take place with the reason: it is no longer overdue and the reason goes into the audit trail. A recurring visit shows each occurrence with its number (#1, #2…); finished ones fold away. An event on event, such as an adverse event, is added with Add: Adverse event and its date, as many times as needed; a log is a table of records. Calendar opens the patient's months. See Events, the patient timeline and the visit calendar.

Finding a patient by ID quickly

Every page of a study has a Patient ID box in the top bar. Press / on the keyboard or click the box and start typing: after the first characters the matching patients appear with their site and status. You can type the start of the ID (TST01-01) or any part of it, as people say it (0112); upper or lower case does not matter.

• The up and down arrows choose a patient and Enter opens the card. When the ID is typed in full or only one patient matches, Enter opens the card straight away.
• When many patients match, All matches in the patient list opens the list already filtered by what you typed.
• The search shows only the patients of your own sites; the sponsor and the statistician have no box. The search writes nothing to the audit trail and stays fast even in a registry of 50 000 patients.
• On a phone the search is a magnifier in the top bar: tap it and the box opens across the whole bar.

Patient status

Use Change status in the card: Completed the study, Withdrawn, Lost to follow-up or Died, with the date the status took effect and the reason. The date cannot be in the future or before enrolment; it shows in the card’s header, in the certified casebook and in the export (the STATUS_ON column). The change goes into the audit trail. From that date no new occurrences of visits are planned, later visits are not counted as overdue, and the patient’s link opens a read-only page. If the patient comes back, set the status back to Taking part: the visit plan carries on.

Lost to follow-up and moves to another site

When a patient has overdue visits, the card shows Attempts to reach the patient. Record each attempt: the date, how (a phone call, a text or messenger, an e-mail, a letter, a home visit, through relatives, from medical records or a registry) and the result. No names or phone numbers here: only what happened. The log shows the monitor and the sponsor that the site did its best before the patient was declared lost to follow-up; it goes into the audit trail and the certified casebook. In site risk, patients lost to follow-up count together with withdrawals.

When a patient moves, the project administrator uses Move to another site: the new site, the date and the reason. The patient keeps the code and all data; the old site’s team no longer sees the patient, and the new site sees it with its whole history. Moves show in the card’s header, in the certified casebook and in the audit trail.

Possible duplicates

One person can end up in a study twice: enrolled at two sites, or again at the same one. Names do not enter the portal, so enrolment has two optional fields for the check: the date of birth and the initials (the first letters of the surname and first name, for example IV or ИВ). The portal keeps neither the date nor the initials: only their fingerprint together with the sex, keyed with the study's secret. Initials in Cyrillic and in Latin letters give the same fingerprint (ИВ = IV), and the patronymic is not used. The date of birth must be in the year of birth.

When the eCRF has a date-of-birth field (BRTHDAT of the standard Demography form, or a field coded BRTHDTC, DOB, BIRTHDATE), the date given at enrolment goes straight into it: the form of the first planned visit that has the field is saved as a draft by the person who enrolled, and the audit trail notes “from the date of birth given at enrolment”. Check the draft and complete the form as usual; nobody types the date twice. This happens only for someone who may enter data, and not while the study waits for the patient’s consent before data entry.

When the study already has a patient with the same fingerprint, a message shows after the enrolment and the pair goes to Possible duplicates; the number of undecided pairs shows on the menu badge. A patient enrolled without the check can be checked later on the patient card, in Duplicate check. The same fields are in the whole-patient workbook (BIRTH_DATE and INITIALS on the patients sheet) and in the API (birth_date and initials).

The study manager, the data manager and the monitor see the page (only pairs with both patients at their sites); the manager or the data manager decides. Different people closes the pair. The same person needs a note of what is done with the second record, for example "REGDIA-02-0004 withdrawn as a duplicate": the portal merges and deletes nothing, the second patient is withdrawn with Change status. The check and the decision go to the audit trail.

Example from the demo

The demo registry REG-DIAB-01 has 16 patients at three sites. REGDIA-01-0005 was enrolled on 07.07.2026: the baseline visit is complete, and the Month 3 cell is a grey dashed frame with “by 20.10”. For REGDIA-02-0005 nothing was entered at baseline within the window, so the cell is a red dashed frame. REGDIA-01-0003 is Withdrawn with the reason “Moved to another city”: the Month 12 visit is no longer expected.

The filter Not completed shows the patients with forms started and not completed, Overdue those with visits not done on time.