Confimedis Plattform v3.0.0

We are happy to announce the next major version of our platform: Confimedis 3.0. This update brings Push and Email Notifications, anonymous Patient Registrations via QR codes, and automated ePRO Invitations with support for repeating events and hourly schedules — along with many quality-of-life improvements.

Features

• Notifications: Notification system
  • Push, email, and in-app notifications can now be enabled per project to automatically inform users and study participants about important events.
  • Initially, four notification types are supported:
  • Query assignments: Sent to a user when a new query is assigned or an existing query is reassigned to them.
  • Subject creation: Sent to all eligible users when a new subject is created, considering permissions and location assignments.
  • Schedule reminders: Sent to study participants when a (virtual) visit is due to be answered based on the event schedule (see below).
  • System announcements: Sent manually by us to inform all users about system updates. Can now be disabled.
  • The preferred notification methods for each notification type can be configured individually for each user.
  • Unread notifications are displayed in the new notifications slideover, accessible from the sidebar and dashboard.
• Surveys: Anonymous registrations
  • Study participants or patients can now have anonymous accounts for a study without needing an email address.
  • Users can create an authentication QR code for a subject, encoding a One-Time Password (OTP), which can be scanned by the participant to join the study.
  • After choosing a password, participants can also install our mobile application on their smartphones or tablets, which allows them to receive push notifications (see above).
• Forms: Repeating limits
  • For repeating events, forms, and sections, an instance limit can now be configured.
  • This limit is visually rendered in the subject list, and after reaching it, no further repeating instances can be created.
  • Additionally, the form status aggregation takes the limit into account, automatically calculating a subject’s or event’s completion progress based on the total number of repeating instances.
• Forms: Repeating visits in event schedules
  • It’s now possible to include repeating visits in the event schedule, while also considering the optionally configured instance limit (see above).
  • For example, a Follow-up visit starting 4 weeks (+/- 7 days) after the Baseline will repeat every 4 weeks (until the optional limit is reached).
  • Each upcoming visit, including the respective time frame and instance (e.g., 3. Follow-up), is rendered in the subject list and calendar.
• Forms: Hourly timing for event schedules
  • Event schedules can now be configured at exact points in time, using 15-minute increments.
  • For example, a diary can be scheduled to be answered every day at 09:00 in the morning and 18:00 in the evening, for a total of 30 days.
• Subjects: Individual schedule per participant
  • Besides a general hourly timing for scheduled events and push notifications, it is also possible to define a custom schedule for each study participant.
  • This can be configured either by the study staff or independently by the participant, if enabled.

Improvements

• Users: Modules are now automatically hidden from the sidebar for users without any read or write permission for those modules. To allow for granular control, new permissions have been introduced for the forms, documents, reports, queries, calendar, and settings modules.
• Subjects: The aggregated form status now automatically switches to Complete when all mandatory fields have been answered, regardless of unanswered optional fields.
• Subjects: In surveys, the pagination indicators at the bottom now consider conditional forms, showing only the number of pages that actually need to be answered.
• Subjects: Surveys via URL or QR code (i.e., without the participant app) now also support repeating study events.

Bug fixes

• Forms: Resolved a local state and rendering issue, where deleted metadata elements (like fields or codelist items) were not visually removed when the containing parent element (like the section or item) was shortly created before.