| Contributors | ||||||
|---|---|---|---|---|---|---|
|
...
|
...
|
...
Table of Contents:
| Table of Contents | ||||||||
|---|---|---|---|---|---|---|---|---|
|
A fully integrated interface between SPARCRequest and OnCore has been developed under the promotion of the Medical University of South Carolina. Roll-out with OnCore enterprise went live in September 2020.
SPARCDashboard → OnCore Minimal Footprint API
The purpose of SPARCRequest having a minimum footprint Interface (7 fields) with OnCore
...
:
...
Easier creation of research protocol and billing calendar outside Epic
...
...
Reduce manual and duplicative data entry
Improve data consistency across systems
Comprehensive reporting
- Enhance communication across providers
User/research provider management
.png?version=1&modificationDate=1607107423247&cacheVersion=1&api=v2&width=600)
CTMS (OnCore) facilitation across the MUSC research enterprise systems
*Principal investigator, Other providers, and Nurses need to have the corresponding “provider’s record” if he/she has been selected to have EMR access.
Protocols (records) that are “Submitted” in SPARCRequest by users are sent to an Epic Queue in SPARCRequest;
If the Epic queue configuration is turned on, the protocols that are interfaced to Epic are sent automatically in a batch mode on daily basis; If the Epic queue configuration is turned off, the protocols are queued and have to be pushed manually by system identified users.
Authorized users can view, send or delete the protocols in the SPARC/Epic queue with the functions described below.
OnCore Log Function (from SPARCDashboard)
In SPARCDashboard, authorized service providers are able to see the “Epic Queue” button (Figure 4), which will allow them to check what studies are in the process of being pushed to Epic.
Figure 4
Epic Queue Page
Once the user clicks the "Epic Queue" button, there are 3 tabs on the page displayed: Current, Past, and Protocol Update tabs.
Figure 5 shows the "Current" tab, where the current queued protocols are listed and waiting to be pushed to Epic. These queued protocols can be pushed or deleted from the queue, and there are URLs linking back to the individual protocols.
Figure 5
When adding or editing authorized users on studies chosen to be pushed to Epic, there is an "Epic EMR Access" choice that authorizes whether a user should have access to Epic (Figure 6). This field is interfaced with Epic real-time, and only allows the choice of "Yes" when the user has a valid EMP record in Epic.
Figure 6
When user rights have been updated for a protocol that have already been pushed to Epic successfully before, that protocol information message will automatically be queued and sent to Epic on the same day at 5 pm. These type of protocols are listed on the "Protocol Update" tab, with detailed information and URL linking back.
.
Figure 7
Previously pushed protocols are listed in the "Past" tab, showing the detailed information about the previous Epic pushes that happened to the protocols, such as PI, last queued date, status, source of the push, and by whom.
There are three types of Epic pushes: Overlord Push, Protocol Update and Admin Push. The Overlord Push is push from the Epic Queue page, Admin Push are the ones done from SPARCDashboard Admin Edit section, and Protocol Update are the automatic protocol information update pushes triggered by user updates (Figure 8).
Figure 8
On the "Past" tab, users can also attach notes to a Epic push with corresponding information if desired (Figure 9).
...
Table 1. Fields Interfaced between SPARCRequest and Epic
Information pushed from SPARCRequest to OnCore comes from the Study Summary section (see Figure 2) and the study calendar section (see Figure 3) of SPARCRequest, which helps build the following pieces in OnCore :
Research study administrative (RSH) record
Study timeline
Study staff
Funding source identification
Participant Privacy Protections
Figure 2
Figure 3
Specific terms in SPARCRequest that match with the ones in Epic are listed below.
...
SPARCRequest Terms
...
Epic Terms
...
Protocol Information
...
General Information
...
Protocol Title
...
Study Name (I RSH .2)
...
PRO # (IRB #)
...
IRB # (I RSH 105)
...
NCT#
...
NCT # (I RSH 181)
...
Protocol ID
...
Study Code(I RSH 100)
...
Reporting Groupers
...
Funding Source
...
Report Grouper - Category List 1 (I RSH 3001)
...
Study Type generated from SPARC Epic box
IDE, HUD, and HDE# (under Investigational Products)
Research Master ID (RMID)
...
Report Grouper - Category List 3 (I RSH 3011)
Report Grouper - Free-Text 2 (I RSH 3002)
Report Grouper -Free-Text 3 (I RSH 3003)
...
Role
...
Study Users (role_code)
...
Primary PI
...
Principal Investigator (I RSH 130) (SER needed)
...
PI/PD; Co-Investigator; Staff Scientist; Postdoctoral scholar, Fellow, or other Postdoctoral Position; Technician
...
Other providers (I RSH 140) (SER needed)
...
Research Nurse
...
Nurses (I RSH 150) (SER needed)
...
Graduate Research Assistant; Undergraduate Research Assistant; Research Assistant/Coordinator; Billing/Business Manager
...
Study Coordinators (I RSH 110) (no SER needed; EMP only)
...
Faculty Collaborator; Consultant; Mentor; General Access User; Other
...
Research Contacts (I RSH 120) (no SER needed; EMP only)
...
Visit Calendar (Billing Information)
...
Study Calendar
...
ARM
...
Protocol (I PRL .2)
...
Visit
...
Visit (CYCLE) (I PRL 200)
...
Day
...
Day (CTTEVENT) (I PRL 400)
...
Window
...
Research tolerance (I PRL 470 [minus], I PRL 480 [plus])
...
Service
...
Component (I PRL 41005)
...
Research/Third Party Payer (R/T)
...
Modifier (I PRL 41007)
...
Epic Questions
...
STUDYTYPE
...
Answers to Epic Questions 1 to 5, Logic-driven
...
Study Type (I RSH115)
OnCore via Minimal Footprint API
OnCore Console | Tab | OnCore Field Name | Field Description | OnCore Field Type | SPARC Field |
PC CONSOLE | Main/Details | Protocol No. | Indicates the main identifier for a protocol. The protocol number displays in the Protocol Header and is used in most reports. The protocol number is used to find a protocol in any of the Select Protocol find-as-you-type fields throughout OnCore. | Alphanumeric; | protocols.id |
PC CONSOLE | MAIN/Details | Title | The title is the name of the protocol study (full length). The title entered here populates to other screens within the OnCore application and is displayed in some reports. The title and short title both populate the SIP Console. Use the SIP Console to select which title format will display on the public website. | Free-Text | protocols.short_title - protocols.long_title |
PC CONSOLE | MAIN/Details | Short Title | Free-Text | protocols.short_title | |
PC CONSOLE | MAIN/Details | Library | The Library associated with a protocol will affect several things within the protocol such as: forms, configuration choices, annotations, signoffs, and reference codes. The Library field will default to the Library associated with the primary Managing Group that is assigned to the user. The Library selection can not be modified after the protocol is submitted. Used in Multi-Department enterprise configurations only. | Special Ref Code | default to "Non-Oncology" |
PC CONSOLE | MAIN/Details | Department | Department that is leading this study. The department selection cannot be modified after protocol is submitted. Used in Multi-Department enterprise configurations only. | Special Ref Code | primary pi's department |
PC CONSOLE | MAIN/Details | Organizational Unit | Organizational Units(OUs) are the highest level category used to group protocols and staff within OnCore. Ous are used to facilitate reporting by major groups and may also be used to limit the scope of a user's access within the context of a protocol, and other user privileges. | Special Ref Code | default to "MUSC Enterprise" |
PC CONSOLE | MAIN/Details | Protocol Type | Protocol Type (equivalent to Primary Purpose) identifies the type of treatment the protocol is using. The Protocol Type is used in the NCI Data Table 4 report and the PHS-398 Enrollment Report. Protocol Search provides a search by protocol type option. The Accrual Monitoring menu item uses the parent category of Protocol Category = Therapeutic as a limiting attribute. | default to "Treatment" | |
PC CONSOLE | Institution | ProtocolInstitution | The PC Console > Institution page is used to display, add, and delete the institutions and study sites that are participating in the protocol. Each is known as a 'participating institution' (or a 'protocol institution') within the context of the protocol. | array | default to “Medical University of South Carolina“ |
PC CONSOLE | Main/Staff | Role = Principal Investigator | Study primary investigator | mapped by netid to interface user if exist | |
Protocols (records) that are created by users in SPARCRequest can manually be pushed from SPARCRequest to OnCore via the “Push to OnCore” button inside of a protocol. Only users with oncore_endpoint_access have access to push records to OnCore.
Information pushed from SPARCRequest to OnCore comes from the Study Summary section (see Figure 1) of SPARCRequest, which creates the initial protocol creation in OnCore.
...
Figure 1
...
Figure 2. Example of a successful Minimal Footprint API Push
Once the initial push was successful, the same protocol cannot be pushed to OnCore again, with warning message shown.
...
Figure 3
...
Figure 4. Record Shows in OnCore
Minimal Footprint API Configurations:
To turn on and utilize the minimal footprint API, the following settings have to be configured:
use_oncore = true
oncore_api =
oncore_default_department
oncore_default_library
oncore_default_organizational_unit
oncore_default_protocol_type
To give specified users access to the interface-related frontend access, users have to be added to the setting below:
7. oncore_endpoint_access
8. oncore_default_institution
9. oncore_default_pi_role
OnCore → SPARC RPE and CRPC Endpoint Interface
In OnCore, SPARCRequest can be configured as an RPE Endpoint destination once the endpoint address is added into OnCore.
...
Figure 5
If a study does not have an existing calendar, OnCore can push a RPE and then CRPC push into SPARCRequest to initiate a study calendar with arms and visits. Note: for a successful push from Oncore to SPARCRequest, be sure to create a “Treatment Arm” in the Oncore PC Console. This denotes that a calendar exists to add it on the SPARC study.
SPARCDashboard OnCore Log Page
In SPARCDashboard, users with the oncore_endpoint_access are able to see the “OnCore Log” button (Figure 6), which lists which protocols have received CRPC pushes from OnCore.
...
Figure 6
Once the user clicks the "OnCore Log" button, they are able to see the OnCore CRPC Push log for protocols that have been pushed from OnCore .
Figure 7 shows the protocols that have both been Successfully and Unsuccessfully pushed, as well as the PI, Calendar Version, Last Push Date, and Push History.
OnCore Log UI | OnCore Log History Window |
|---|---|
 |  |
Figure 7
Technical Specs
Format: Health Level Seven (HL7) messaging, based on an XML encoding
Protocol: Simple Object Access Protocol (SOAP)
The API can be used for other
...
Clinical Trial Management Systems as a template
...
For more details about the minimal footprint API, please check the links below to the GitHub codes: https://github.com/sparc-request/sparc-request
...
/blob/36113d1c28e5ef6f7cc8118fb741ef515a8d8bf0/app/lib/oncore_protocol.rb
For more details about the RPE/CRPC endpoint API, please check the
...
link to the GitHub codes:
...
...
...
...
...