Contributors | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
TABLE OF CONTENTS
Table of Contents | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
SPARCRequest and Epic Interface
...
Background
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.
...
Figure 1 Functionality and Overlap between SPARCRequest and Epic
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Data Exchange
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:
...
*Principal investigator, other providers, and Nurses need to have the corresponding “provider’s record” if he/she has been selected to have EMR access.
...
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
SPARC Setup Requirements for 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
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Epic API Behavior on SPARC Submitted Studies
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 push.
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Epic Queue
...
Functions (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.
...
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.Anchor Pasttabqueue Pasttabqueue On the "Past" tab, users can also attach notes to an Epic push with corresponding information if desired (Figure 10).
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
EPIC Pushes and Queuing
Epic Pushes
There are three types of Epic pushes:
...
Protocol Update - automatic protocol information update pushes triggered by user updates (Figure 13)Anchor Protocolupdate Protocolupdate
...
Figure 13
Jump to Section:
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Technical Specs
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 Electronic Health Record (EHR) Systems as a template
An example SOAP message can be found here: https://github.com/sparc-request/sparc-request/wiki/Epic-XML-example
For more details, please check the links below to the GitHub codes: https://github.com/sparc-request/sparc-request/blob/master/lib/epic_interface.rb
...