OpenClinica 4 Stack 6.1 (Release Date – 26 October, 2018)
OpenClinica 4 Stack 6.1 contains a variety of minor enhancements and fixes to OpenClinica. View the entire Stack 6.1 changelog here (login required).
- Added support for Randomize module. This module allows study-specific participant randomization algorithms to be used.
Changes & Fixes:
- Fixed an issue where SAS dataset extracts were grouping data incorrectly in some cases.
- Fixed an issue where system-generated Participant IDs were not created according to the ID template in multi-user scenarios.
- Fixed an issue where the on-form Query Widget Assign To dropdown did not contain all expected users.
- Updated Clinical Data API to support XML format.
OpenClinica 4 Stack 6 (Release Date – 13 September, 2018)
OpenClinica 4 Stack 6 contains a variety of enhancements and fixes to OpenClinica. View the entire Stack 6 changelog here (login required).
For an overview of the update, view the Stack 6 Release Announcement here.
Study Build System
- Added ability to create custom roles with permission enabled per form. Added a User Roles page to configure User Roles per study. Each custom role can be configured to have a unique name, a description, and a base role. The base role determines what actions the custom role can perform (for example, events can be signed by custom roles based on Data Specialist or Investigator, SDV can be performed by roles based on Monitor, etc.).
- Up to one permission tag can optionally be added to each form in Study Designer. All forms are untagged by default. Once a permission tag has been created, it can be enabled per custom user role on the User Roles page. By default, all custom user roles have access to only untagged forms. If a permission tag is enabled for a custom role, then users in that custom role will also have access to all forms that have that permission tag.
- Permission Tags are used to restrict access to clinical data on forms by user role in Runtime. Users will not have access to form data if the form is tagged and the users’ role does not have the tag enabled. Note that a form that is defined to pull in cross-form data will pull in data regardless of the viewing user’s role. For this reason, the study designer must be careful if a form is designed to pull in data from another form with a different permission tag.
- Changes to form permission tags are included in the Study Designer Activity Log.
- Changes to custom roles are included in the User and Role Audit Log accessible from the Administration page.
- Added Participant ID configuration at the study level (accessible via the Study Settings page). IDs can be configured to be entered manually or system-generated automatically. If the ID is system-generated, an ID template can be configured. The Template supports settings Participant IDs based on the current participant count in the study and including the Site ID (or Study ID, for study-level participants) and optional study-defined separators or other text. For example, a study could be configured to automatically generate the ID “Site123-0025” for the 25th Participant added at the Site with ID “Site123”. The Participant ID configuration can be modified during the life of the study as needed.
- Added Participant Limit configuration at the study level (accessible via the Study Settings page). If desired, a study can be configured to use the “Expected Number of Participants” as a hard limit on adding new participants. If this option is used, Participants will not be able to be added to the study if the Expected Number of Participants has been reached (excluding Removed Participants). This includes participants created within a site or at the study level. If this option is not used, then there will be no limit to the number of participants that can be created.
- Added link to Swagger UI to the Administration page. This allows users to view and test system APIs.
- If the study has permission tags defined for any forms, users will only be able to access tagged forms if the users’ roles have these permission tags enabled. All users have access to untagged forms. If a user has access to a form based on the form and role permission tags, the user will have the ability to perform all of the functions on the form that the user’s base role is permitted to do (for example, roles based on Monitors can SDV forms).
- If a user does not have permission to access a form, they will not be permitted to open the form in edit mode, review-only mode, or read-only mode, they will not permitted to view queries on the form, they will not be permitted to SDV the form, extract the form clinical data in a dataset or participant casebook, view common event tables for the form on the Participant Details page, or otherwise view clinical data for the form. The user will still be permitted to view a blank copy of the form or the metadata for the form.
- If the user does not have permission to access a form, the form will not be listed in the SDV table and queries on items in the form will not be listed in the Query Manager table. The user will still be able to see the status of Visit-Based event forms in the Participant Matrix, Participant Details page, or Enter or Validate Data page, however, the user will not be permitted to open, remove, delete, or reassign the version of the form.
- All users will be permitted to define a dataset extract to include any forms in the study. However, when the extract is generated, only data from forms the user is permitted to access will be included in the dataset file. When a dataset is generated and the resulting file does not contain all data defined to be part of the dataset definition due to form permissions, the resulting filename will start with “filtered”. Additionally. once a dataset file is generated, only users who have permission to access all forms that are contained in the dataset file will be permitted to download or delete the dataset file. If a user does not have permission to download an existing dataset file, they will be permitted to run the dataset again to create a new file that contains only data from forms that the user is permitted to access.
- When a user views the Audit Log for a Participant, entries will be shown for all data changes. However, if the user does not have permission to access a form, the old value and new value will be masked.
- If the user clicks a link for an action they are not allowed to perform due to permission tags, the user will see either a popup message or new page showing a message about the lack of permissions.
- If the study is configured to use system-generated Participant IDs, when adding a new Participant, the user will not be able to enter a Participant ID. It will be generated when the Participant is created.
- If the study is configured to use system-generated Participant IDs, existing Participant IDs cannot be modified.
- The Participant ID configuration has been added to the View Study page.
- If the study is configured to limit the participants and the maximum number has been reached, the Add Participant links in Runtime will not be displayed for any users.
- If a user loads a page with the Add Participant link and another user adds a participant to reach the cap, when the first user clicks the Add Participant link a message will be displayed that the limit has been reached and a participant cannot be added.
- The Participant Limit configuration has been added to the View Study page.
- Fixed issue where Site ID changes from Study Manager did not get displayed in Runtime.
- Added a REST API to add a single participant.
- Added a REST API to get the list of existing participants.
- Added a REST API to import data.
- Added a new feature (available via REST API) to bulk create participants by including a file containing the participant IDs to be created.
- Added ability to import data into new forms in common events.
Changes & Fixes:
Study Build System
- All studies were automatically updated to replace the existing 7 standard roles with 7 equivalent custom roles. All roles are the same except study-level Monitor is now called “Study Monitor” and site-level Monitor is now called “Site Monitor”. All existing users continue to have the same permissions as before.
- Study Designer has been updated with improved filtering by Label and Member (and Permission Tag filtering has been added).
- Added a Gear Icon navigation button to Study Designer and the Share Study page to enable quick access to the Study Settings and User Role pages.
- Fixed an issue where publishing a study was failing in certain cases when two forms had similar names (the same first five non-space characters) and the forms had items or item groups with the same name and the second form was overwritten after it had been published.
- Fixed an issue where adding a Site to a study as a new site when it already exists in a different study could result in the study being created in Runtime but appearing to fail in Study Manager. This case now causes the operation to fail and instructs the user to try again.
- Fixed an issue where inviting an existing user to a new study was resetting their status to invited.
- Fixed an issue where renaming a form that is used in multiple events could trigger an error message.
- Fixed an issue where users might not be logged out of Study Manager in certain cases when their computers went into sleep mode.
- Fixed an issue in Study Designer that caused performance to degrade over time.
- Updated Share Study page column title from Version to Revision to match the terminology elsewhere in the system.
- Updated Share Study Page to show Date and Time of each publish operation rather than just the Date.
- Removed configurations for deprecated fields Person ID, Sex, and Date of Birth from the Study Settings page.
- The User Menu in the top right corner of the screen and the Change Study page have been updated to show the current user’s custom role name.
- The Monitor user at the study-level is now called “Study Monitor”. The Monitor user at the site-level is now called “Site Monitor”.
- Updated Query Manager table to persist filtering and sorting when the user opens a form from the table and returns to the table after closing the form.
- Updated the Query Manager table to default to sorting by Days Since Updated, then Site ID, and then Participant ID.
- Added Quick Links section to the left panel with a link to “Queries Assigned to Me”.
- Fixed an issue where adding a query to a form was changing its status from Complete to Data Entry Started.
- Fixed an issue that was causing Reasons for Change to be set to Closed status if the form they were on was archived, removed, or deleted. Now these remain with Not Applicable status as expected.
- Fixed an issue where queries which were auto-closed due to the form they were on being archived, removed, or deleted not showing the auto-closure text in the Query Manager table.
- Updated the Participant Audit Log to refer to the “Participant” rather than the “Subject” for consistency with the rest of Runtime.
- Fixed an issue that displayed the wrong username in the message displayed when a user attempted to delete a form that was locked for use by another user.
- Fixed an issue where a participant was incorrectly marked as signed if they only had one event started and it was signed.
- Fixed an issue where changing data for a signed participant did not automatically un-sign the participant.
- Fixed an issue in the data import template where “complete” status was incorrectly listed as “completed”.
- Fixed an issue in rare cases where the Participant ID link in the Participant Matrix might link to a different participant’s details page.
- Fixed an issue where Admin users who were not Data Managers could lock events. Locking permission is now available only to Data Managers.
- Fixed an issue where an archived form could be deleted. This scenario was putting the form in an unstable state.
- Fixed an issue where the Participant Details page couldn’t be loaded immediately after publishing a study.
- Removed deprecated fields Person ID, Sex, Secondary ID, Enrollment Date, and Date of Birth from throughout Runtime.
- Removed Filter by Enrollment screen from the dataset definition workflow.
- Updated the Add Participant and Edit Participant windows to standardize the UI.
- Updated UI on Reassign Participant, Remove Participant, Restore Participant, View Study, and View Site pages.
- Fixed an issue where entering only spaces into a required text item would satisfy the requirement and not show an error that the field was required.
- Added support for forms with item type text and appearance “url”. This item can be populated with a URL by a calculation and the resulting link will be displayed prominently after the item label.
- Fixed issue where the Close and Complete buttons moved down slightly when data was saved to a form for the first time in a session. This caused some clicks to miss the buttons when they moved.
- Fixed an issue where a user opened a form using the View Query Within Record link in the Query Manager table and the item the query belonged to was either hidden or removed from the form. In this case, it was not displaying a message about this circumstance to the user.
- Fixed an issue where the Query Widget’s Assign To list was not always populated with the current list of users and did not necessarily reflect the latest role updates or name changes to the users.
- Fixed an issue where the formatting of the timestamp in the Query Widget was not padded correctly for day values less than 10.
- Fixed issue where file upload items did not have download buttons in IE11.
- Fixed issue here the Query Widget did not render correctly in IE11.
- Fixed issue where form width was unstable in IE11.
OpenClinica 4 Stack 5.1 (Release Date – 5 July, 2018)
OpenClinica 4 Stack 5.1 contains a variety of minor enhancements and fixes to OpenClinica. View the entire Stack 5.1 changelog here (login required).
Changes & Fixes:
- Updated the General Information section of the Participant Details Page to remove the following fields – OID, Person ID, Secondary ID, Sex, Date of Birth, and Enrollment Date.
- Fixed an issue where opening a form using the View Query Within Record link from the Query Manager page was causing an error message to be displayed if the form being accessed was in a Locked Event.
- Fixed an issue where the timestamps shown in the History section of the on-form Query Widget were not displaying the correct date and time in some cases.
- Updated the Add Participant and Update Participant pages to remove all fields except Participant ID. The following Participant data fields have been removed – Person ID, Secondary ID, Sex, Date of Birth, and Enrollment Date. If this data is needed for a study, the appropriate fields should be added to a standard Visit-Based Event Form or Common Event Form.
- Updated the Add Participant and Update Participant pages to remove the fields that allowed a user to schedule the new Participant’s first Event. After the new Participant is created, the user can schedule an Event as needed from the Participant Matrix, Participant Details Page, or Schedule Event link.
OpenClinica 4 Stack 5 (Release Date – 28 June, 2018)
OpenClinica 4 Stack 5 contains a variety of enhancements and fixes to OpenClinica. View the entire Stack 5 changelog here (login required).
For an overview of the update, view the Stack 5 Release Announcement here.
- Concurrency Locking functionality has been added to prevent concurrent data entry into the same record by different users. When a user opens a form in edit mode or review-only mode (i.e., queries only mode), they will acquire a lock on it. Any other user attempting to open the locked form will automatically open it in read-only mode. Additionally, locked forms cannot be deleted, removed, or reassigned by other users. If a user is prevented from performing an action due to another user having a lock on a form, a message will tell the user who currently has a lock on the form. The user’s lock on the form will be released when the user closes the form via the Close or Complete buttons or when the user’s session expires due to inactivity.
- Updated the Participant Details page to make the page view settings persist during a user’s session. Filtering, sorting, etc., of the Common Event tables will persist when the user navigates back to this page. Page view Persistence is Participant-specific. The page view can be reset at any time by clicking the “Customer View On” button. It will reset automatically when the user logs out or changes to a different study.
- Added ability for all user roles (except Monitors) to remove and restore events and forms.
- Improved external API coverage and added a user access token system for using the APIs.
Study Build System
- Added a feature to download the Excel form definition for an archived form version in Study Designer. This is accessible from the Archives.
- When a form is being printed using the on-form Print button, the user is now prompted to choose whether to include item history. If history is not included, the printed version of the form will contain only the data items on the form. If history is included, the print form will include the data items on the form and the history of each item (for example: value changes, queries, and reasons for change).
Changes & Fixes:
- The terms ‘Subject’ and ‘Study Subject’ have been replaced with ‘Participant’ throughout OpenClinica. The Subject Matrix is now the Participant Matrix, Add Subject is now Add Participant, etc.
- Fixed an issue where the SDV interface was not displaying the correct form version information after a form was migrated to a different version.
- Fixed an issue where a user attempting to navigate from Runtime to the My Studies, My Profile, or Administration pages would sometimes be bounced back to Runtime.
- Fixed an issue where some users were redirected to their home screen when they attempted to edit their information on the My Profile page.
- Fixed an issue where Data Managers would sometimes get redirected to the Change Study page after leaving the My Profile page.
- Fixed an issue that was preventing a success email from being sent to a user when their extract finished generating.
- Fixed an issue where Query notification emails showed the incorrect “updated by” user.
- Fixed an issue that was causing repeating events to be displayed in the Participant Matrix with their creation date rather than their Start Date.
- Fixed an issue that was not allowing forms in a Stopped event to be edited. If a form in a stopped event is edited now, the event is automatically changed back to Data Entry Started status.
- Fixed an issue where updating an event’s status from Stopped to Data Entry Started was sometimes changing the status of forms in the event from Data Entry Started to Complete.
- Fixed an issue where form data could be imported for multiple versions for the same form in the same event for the same Participant.
- Fixed an issue where the ending form status defined in the import data file was not being respected during the import process.
- Fixed an issue that allowed non-Data Managers to access the locking interface for Common events.
- Fixed an issue where a user was able to delete a form in a locked event.
- Fixed an issue that caused an Edit button to be displayed for “Not Started” forms within locked events.
- Fixed an issue that caused Common Event forms defined as hidden to be hidden from study-level users. These forms are now correctly hidden from only site-level users.
- Fixed an issue where an existing form in a Common Event remained editable for a Participant even after the form was archived.
- Fixed an issue where an existing form in a Common Event remained editable for a Participant even after the Participant was removed.
- Fixed the label of Site ID in several pages where it was mis-labeled.
- Updated the icon key to be consistent for all user roles and to include missing actions/status.
- Updated the icon key and Participant Matrix/Participant Detail page to differentiate between the icons for Signed (status) and Sign (action).
Study Build System
- Fixed an issue where publishing a large study would fail after 5 minutes. The publish timeout is now 1 hour to allow for very large studies to be published.
- Fixed an issue where publishing a study fails when certain forms have been archived.
- Fixed an issue where form upload would fail if there was already another version of the form and the version names of the forms were very similar (for example, the same except for non-alphanumeric characters).
- Added validation to prevent uploading/publishing forms that exceed the system maximum length of a code list of 4,000 characters. If a single form version exceeds this limit an error message will be displayed at form upload time. If the limit is not exceeded by a single version of a form but is exceeded collectively by the combination of all versions of a form, an error message will be displayed at study publish time.
- Fixed an issue where user logins were sometimes not being recorded consistently.
- Fixed an issue where updating a user’s role or type was not updating the “Updated” column in the User tables on the Share Study and Administration pages.
- Fixed an issue where a user logging into the system was incorrectly updating the “Updated” column in the User tables on the Share Study and Administration pages.
- Fixed an issue where inviting an existing user to a new study would change the user’s status to “Invited”.
- Fixed an issue where in certain circumstances a user could log into a study they had recently been removed from.
- Fixed an issue where forms would sometimes not be able to be reordered in Study Designer.
- Updated the Form Template in Study Designer to reflect functionality changes in this release.
- External data read capability has been expanded to allow the current form user’s username and user role to be loaded into a form. This can then be used in logic on the form (for example, to make a note item visible to only users in a specific role).
- External data read capability has been enhanced to retrieve external data when a form is opened in read-only or review-only modes. If the external data is displayed on the form (such as in an item label), it will now be displayed in those modes. Note that calculations will only be evaluated and displayed/submitted for forms opened in edit mode.
- The on-form Query Widget has been updated to include the full timestamp of each item in the History section (instead of just a relative timestamp).
- Fixed layout issues that caused incorrect “Required” error message placement for certain item type/appearance type configurations.
- Fixed an issue where forms were not displaying correctly on smaller screens (such as on tablets or phones).
OpenClinica 4 Stack 4.1 (Release Date – 9 May, 2018)
OpenClinica 4 Stack 4.1 contains a variety of minor enhancements and fixes to OpenClinica. View the entire Stack 4.1 changelog here (login required).
- The on-form Print icon has been restored. Existing forms and blank forms can be printed.
Changes & Fixes:
- Improved study publish performance. Publishing a study typically takes less than half as long as it did before this release.
- Improved performance of Study Designer as additional forms are added to a study.
- When an item of type “file” is added to a form, it will automatically accept files of any type without requiring additional configurations.
- Updated mail server configuration to reduce the likelihood that user invitation emails will be flagged as spam.
- Fixed an issue where the “clear” button to remove files that were uploaded to a form was not removing the uploaded files as expected.
- Fixed issues where manually typed or pasted dates that were in the wrong format were not rejected as expected.
- Fixed form layout/spacing issues with the Query icon and multi-line label text.
OpenClinica 4 Stack 4 (Release Date – 17 April, 2018)
OpenClinica 4 Stack 4 contains a variety of enhancements and fixes to OpenClinica. View the entire Stack 4 changelog here (login required).
- Added support for non-visit-based events (known as “Common Events”). Repeating Common Events can be used to achieve repeating form functionality for use cases such as Adverse Events or Concomitant Medications. Non-repeating Common Events can be used for single-entry forms such as Early Termination.
- Redesigned Subject Details page to support both visit-based events and common events and make the UI more user-friendly. Each Common Event is displayed in a separate collapsible section. Common Events can be configured to display form data as part of the table view on the Subject Details page. Common Events tables have new sorting, filtering, and pagination functionality.
- Added customer-wide People table to the Administration page. This includes a Deactivate option to remove user access at the customer level. (Note that user access can also still be removed per study.)
- Added new file types for file upload items on forms. The following items are now supported (in addition to image): audio, video, and file (for generic files).
- Three drawing items are now supported – draw (for drawing on blank canvas in multiple colors), annotate (for uploading an image and then drawing on it in multiple colors), and signature (for collecting a black and white signature). Each of these are saved as image files.
Changes & Fixes:
- On the Subject Matrix, each Subject ID is a link to go to the Subject Details page for that subject. This is helpful if the Subject Matrix is very wide.
- Improved cross-form logic performance by making only subject clinical data accessible (not study metadata).
- Uploaded files and drawings can now be downloaded directly from a form. The UI for uploading/removing files has been improved to prevent accidental file removal.
- When inviting users to a study, you can search for existing users by name, username, or email address.
- Updated the Share Page People table in Study Build System to have more user-friendly pagination and to make most columns sortable. Date columns now show both date and time. User Status is now included in the table.
- When uploading a form, style “no-text-transform” is automatically applied to the form so that it doesn’t need to be specified manually. This ensures that forms display label text case-sensitively.
- When uploading a form, appearance “no-collapse” is automatically applied to each group so that it doesn’t need to be specified manually. This ensures that the form user does not accidentally collapse a group and hide data unintentionally.
- Improved performance and functionality support for Internet Explorer and Edge browsers.
- Removed Print icon from on-form view.
OpenClinica 4 Stack 3 (Release Date – 15 February, 2018)
OpenClinica 4 Stack 3 contains a variety of enhancements and fixes to OpenClinica. View the entire Stack 3 changelog here (login required).
- Added support for Cross-Form logic. External Values can be pulled into a form for use in calculations, constraints, hide/show, conditional required, and display piping.
- User invitations can be resent from the Study Build System.
- Reason for Change entries can be viewed from the Query Manager.
Changes & Fixes:
- Single Sign-on enhancements
- Improved appearance of embedded documentation.
Click here to view previous updates