SPARCRequest Wiki

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

Brigette White 19 (32 days ago), Kyle Hutson (Unlicensed) 4 (1058 days ago), Wenjun He (Unlicensed) 5 (1709 days ago), harikrip 2 (1709 days ago)

SPARCRequest and Epic Interface Information


A fully integrated interface between SPARCRequest and Epic has been developed under the promotion of the Medical University of South Carolina. Roll-out with Epic enterprise went live in July 2014.

The purpose of SPARCRequest having an Electronic Health Record (EHR) Interface with Epic (as shown in Figure 1):

  • Easier creation of research protocol and billing calendar outside Epic

  • Uniform research pricing and improved billing compliance

  • Reduce manual and duplicative data entry

  • Improve data consistency across systems

  • Comprehensive reporting

  • Enhance communication across providers

  • User/research provider management

Figure 1 Functionality and Overlap between SPARCRequest and Epic

Information pushed from SPARCRequest to Epic mainly comes from the Study Information and Authorized Users sections (see Figure 2) and the study calendar section (see Figure 3) of SPARCRequest, which helps build the following pieces in Epic:      

  • Research study administrative (RSH) record

  • Study timeline

  • Study staff

  • Funding source identification

  • Participant Privacy Protections

Figure 2

Figure 3

The NCT# and IRB initial approval and expiration dates entered into SPARC in study details are also pushed into EPIC (see Figure 4).

sparc-epic nctn irb dates.png


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 Approval Number (I RSH 105)

Initial IRB Approval Date

Approval Date (I RSH 106)

IRB Expiration Date

Expiration Date (I RSH 107)

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)

*Principal investigator, other providers, and Nurses need to have the corresponding “provider’s record” if he/she has been selected to have EMR access.


Criteria for SPARC Services Using Epic

To use the SPARC-EPIC Interface, services should be set up accordingly:

  • Within SPARCCatalog for the service:

    • Epic ‘tag’ is chosen in ‘General Information'

    • Corresponding ID or code is entered and ‘Send to Epic’ is On in ‘Epic Interface’

  • Protocols (records) should indicate ‘Publish to Epic' on the study ‘Confidentiality and Epic Questions’ section, with an Epic-enabled service included on a service request. In addition:

    • At least one clinical service with the Epic tag must be on the study

    • No special characters are within the study title or arms names

  • EPIC Users: 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 5). 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.  In addition, a warning message will display under the Authorized Users tab in SPARCDashboard when a protocol is chosen to be sent to Epic, but the PI does not have Epic access (a common use case is when a PI has not completed the required Epic training to have this right) (Figure 6).

Figure 6

When the protocols are “Submitted” in SPARCRequest by users, they are then sent to an Epic Queue in SPARCDashboard:

  • If the Epic queue configuration is turned on, the protocols that are interfaced to Epic are eligible for queuing to be sent automatically in a batch mode on daily basis. This is the current set-up at MUSC.

  • If the Epic queue configuration is turned off, the protocols are queued and always 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.

  • SPARC study changes (e.g., NCT# or IRB dates) do not put the study into an Epic queue (see below queues - Current, Protocol Update) for automatic updates to the EPIC study record. For automatic queuing, those types of SPARC protocol changes must accompany clinical (calendar) services or personnel updates. However, manual updates can be sent with an Admin Edit push.


Epic Queue Function (from SPARCDashboard)

In SPARCDashboard, authorized service providers are able to see the “Epic Queue” button (Figure 7), which will allow them to check what studies are in the process of being pushed to Epic.

Figure 7

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 8 shows the "Current" tab, where the current queued protocols are listed and waiting to be pushed to Epic.

  • Protocols are sent into the "Current" tab when new clinical services are added or changed in the study calendar. 

  • These queued protocols can be pushed or deleted from the queue, and there are URLs linking back to the individual protocols in SPARCDashboard. 

  • If there are also no SPARC authorized users change, the protocol must be pushed from the "Current" tab to update EPIC, which will be an immediate update.


Figure 8

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 (Figure 9), with detailed information and URL linking back to SPARCDashboard.

Figure 9


  • 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.

    • On the "Past" tab, users can also attach notes to an Epic push with corresponding information if desired (Figure 10). 

Epic Pushes

There are three types of Epic pushes:

  • Overlord Push - from the Epic Queue page (Figure 11)

epic overlord push.png

  • Admin Push - completed within SPARCDashboard Admin Edit section (Figure 12)

epic admin 2 push.png

  • Protocol Update - automatic protocol information update pushes triggered by user updates (Figure 13)

Figure 13


Technical Specs




  • No labels