Research Master ID
SiteNew Features and Bug Fixes (
v1version 1.2.5)
1.
(RMID
/eIRB API) Update ConfigurationRMID configuration has been updated to coincide with the recently updated eIRB server settings.
.(RMID) Change API Data Refresh Schedule
Background: eIRB imaging site creates the snapshot data every 15 minutes from 10, 25, 40, 55 of every hour.In order to shorten the time in-between the RMID data refresh and the eIRB one, so that the updates made in eIRB system is reflected more timingly, we should change the RMID eIRB refresh schedule to every hour (7:05, 8:05, etc) instead.
(RMID) eIRB API Update: Add eIRB Fields
Background: Now that the 3 ) Visual Indicators Added for Associated Protocols from Different Systems
In this release, visual indicators have been added to better represent the association of protocols from different systems to the Research Master record:
- Color legends have been added to indicate whether there are protocols associated, and the different colors represent different systems, blue for SPARCRequest, green for eIRB, and red for COEUS.
- The same color legends are also displayed next to the corresponding protocol types after the user clicks on the RMID record and enters the "Associated Protocols" popup window.
- The "Associated Protocols" popup window now also displays the RMID number associated in the title. (i.e. "RMID: 1")
2. (RMID) Additional eIRB Fields Added in Backend
In this release, the three eIRB dates (Initial eIRB Approval Date, Current eIRB Approval Date, eIRB Expiration Date), besides Pro#, are now pulled into the RMID backend , we need to expose these attributes and exposed via the RMID API so that they can be used in SPARCRequest. In addition, the eIRB Pro# should be exposed.
(RMID API) Expose CoeUs Project ID
(RMID) Research_masters. department Migration to Users Table
For the pi_department information that's currently stored in the research_masters table, could we integrate that into the users table as well, or reference out to the existing departments table?
Department (affiliation) logically is tied with the user.
Note that this is also part of preparation for us to unify the department fields for each user to get ready for using a single source in the future (from PRISM or else).
(RMID) Protocol PI Update for Complete eIRB Studies
When a PI moves to a different institution, their eIRB netID column gets updated to the new institution, which caused problem for RMID logic when trying to update the PI accordingly.
Please add the logic . These fields were added in order to be shared back to auto-fill SPARCRequest.
3. (RMID) Holding PI Information for Completed eIRB Studies
In this release, use cases have been discussed by RMID stakeholders for when a PI moves to a new institution. The PI move caused issues updating eIRB profiles for studies that were already completed. In this release, logic was added to the eIRB/RMID API, so that PI-related protocol fields (First Name, Last Name, net_id) do not get updated are not updated for eIRB protocols under "Completed" state. This was done to keep the integrity of user data, since eIRB PI updates the RMID PI, which is linked with MUSC identity management systems and are restricted to MUSC employees (with their musc.edu email and netID).
4. (RMID/eIRB API)
API Cronjob ImprovementsThe RMID cronjob to update data every 4 hours from SPARC, eIRB and coEUS some times stops working without any signs, please:
Better exception handling. So that failures are captured and e-mailed to the development emails and sparcrequest@musc.edu
Optimization: for better efficiency of the updating logic, instead of reseting all the values and start-over every time. Note that based on 9/26 record, the eIRB refresh alone took more than 30 minutes.
Start/completion notifications.
(RMID) Add Visual Indicators for Associated Protocols from Different Systems
1). On the "Associated Protocols" popup modal, please add the "(RMID: 1)" to display the RMID number.
2). Add color legends on the RMID record to indicate whether there are protocols associated, and use different colors to represent different systems.
(RMID) Adding COEUS Project ID
As a prep work for a SPARCRequest new feature: we need to bring in COEUS project ID (SRC_ORSP_AWARD_DETAILS.ACCOUNT NUMBER) into the protocols table, as one of the fields usable for RMID/SPARC API.
(RMID) Missing net_id in primary_pis
There were previous Null values for the primary_pis.net_id and email columns.This data issue bug has since been resolved.
(RMID) Different Users with Same NetID Bug
There are 30 couples of users in RMID currently have the same NetID (see attached), which shouldn't be possible.
Query used:
select *
from users users1
join users users2
on users1.`net_id` = users2.`net_id`
and users1.`id` != users2.`id`
NetID should be unique for each user.
Please look into the cause of the issue for a fix.
(RMID) Repetitive Auditing Issue
It seems that RMID audit trail is recording hundreds of the same entry (updating back and forth) for the same data row. Please look into this and optimize the update and save audit time.For example, when looking into the audit records of RMID 2074 on production, there were 2728 versions of this row of data, and they were updating the same field with the same contents back and forth.(RMID)
(RMID)
Copyright © 2017-2018 MUSC Foundation for Research DevelopmentUpdated eIRB Connection Configuration and Refresh Schedule
The RMID/eIRB API configurations on both the production and staging sites have been updated to coincide with the recently updated eIRB server settings.
With the upgraded eIRB database, it is now possible to get fresh data more frequently without slowing down systems. From this release, the RMID/eIRB API is scheduled to update every hour (7:05, 8:05, etc), in order to shorten the reaction time. By changing the update schedule, the RMID system will better reflect the eIRB updates.
5. (RMID) COEUS Project ID Added to RMID/COEUS API
The project ID field from COEUS (i.e. the UDAK "Project Key") has been added to the RMID/COEUS API to update the RMID backend. This was done as preparation to display this information to frontend users, and auto-fill the (partial) UDAK number in SPARCRequest in the future.
6. (RMID) Improved API Performance and Status Notification Mechanism
To better observe the API status between RMID and other connected systems, the following improvements have been made to the hourly refresh job from RMID to SPARC, eIRB and COEUS systems:
1). Exception handling to capture failures and real-time notification to the development team;
2). Optimization for better efficiency of the protocol association and PI update logic;
3). Start and completion notifications have been added (on the development Slack channel for development team).
7. (RMID) PRISM API Integration and Auto-fill PI Department
The Provost Information System (PRISM) is the database managed by MUSC provost office for all MUSC investigators, and is the record-of-truth system for the PI's main appointment department. In order to pull the department information directly from the source and auto-fill for users who are in that system for more accurate affiliations, we have established the RMID/PRISM API to pull in department information when a PI is searched and chosen for an RMID record.
- When a user creates or edits a Research Master record and chooses a PI from the search results, and that PI exists in PRISM, his/her affiliated department is now auto-filled, and the field become disabled (non-editable).
- When a user creates or edits a Research Master record and fills out the PI, and that PI does not exist in PRISM, the department field is still editable to allow manual entry.
8. (RMID) Storing PRISM Department Information on RMID Users
With the newly established RMID/PRISM API, we are now pulling and storing the department information (if it exists) with the logged-in RMID user through the API, for future reporting purposes. Furthermore, we are working on migrating/cleaning up previously manually entered PI department information in RMID according to PRISM data in the next release.
9. (RMID) Duplicated NetID Bug Fix
There was a previous bug that stored the same NetID for a dozen pairs of users in RMID. This bug has since been fixed.
11. (RMID) Repetitive Auditing Entries Bug Fix
The RMID audit trail was previously recording hundreds of the same entries for the same data row because of flawed logic. In this production, the bug has been fixed.