Getting Data after EPIC
Robert Morrell, MBA
Systems Manager
Comprehensive Cancer Center of Wake Forest University
The promise and the tragedy
• “Meaningful use” promised better normalized
data
• Getting data out during/after implementation
was not a priority
• Support Staff often did not yet understand the
new system well enough to get the data
quickly
Wake Health and CCCWFU
• Previously used GE (Logician/Carecast) as well
as IDX
• Converted to EPIC September 2012 (Big Bang,
not recommended)
• CCCWFU had previously built snapshot
mediated links between its legacy CTMS to
inpatient, outpatient, labs
• Numerous applications utilizing these linkages
developed over 10 years
Direct EPIC, Data warehouses, and
Clarity
• Previously we had used direct system data
dumps as well as dumps from a data
warehouse
• Once EPIC launched there was no direct data
link (yet) and the data warehouse was not
initially being fed
• Clarity: not a data warehouse, (Cogito is the
data warehouse which we do not yet use)
Things learned at great cost
• EPIC data models were much more granular and
getting the data became more difficult.
• The old data in the EDW should be transformed
to look like the new data coming in, not the
reverse
• Knowing EPIC does not mean you know Clarity
• Clarity run schedules must re done to match your
data hierarchy or there will be blood
• Do not let your EDW be driven by the first or
loudest report/data requests. Design, plan and
implement
4 datasets, 3 methods
• Outpatient schedule and inpatient census:
– Clarity->Crystal reports->BOE scheduler->file on
CCCWFU server->CCCWFU SQL database
• Labs
– Clarity->EDWS (Oracle)<->Link Server<->CCCWFU
SQL database
• Research Status (new)
– Clarity->Reporting Work Bench->file on CCCWFU
server->CCCWFU SQL database
SELECT /* PARALLEL */
PE.PAT_MRN_ID mr_nbr,
ors.result_time ordr_dtetime,
NVL (ORP2.SPECIMN_taken_TIME, SPECIMN_taken_date)
SPECIMN_taken_TIME,
MAX (ors.ord_value) rslt,
CC.BASE_NAME tst_rslt_cde,
CC.NAME tst_rslt_desc,
ors.reference_unit unit
FROM CLARITY.order_results@edws2clarity ors,
CLARITY.patient@edws2clarity pe,
clarity_component@edws2clarity cc,
clarity.order_proc_2@edws2clarity orp2,
clarity.order_proc@edws2clarity orp,
EDWSCUST.MORELLCANCER_MRN mm
WHERE ORP.ORDER_PROC_ID = ORS.ORDER_PROC_ID
AND ORP2.ORDER_PROC_ID = ORP.ORDER_PROC_ID
AND ORP.pat_id = ORS.PAT_ID
AND pe.pat_mrn_id = TRIM (mm.pat_mrn_id)
AND PE.PAT_ID = ors.pat_id
AND ors.component_id = cc.component_id
AND TRUNC (ors.result_time) > TRUNC (SYSDATE - 21)
GROUP BY pe.PAT_MRN_ID,
ors.result_time,
ORP2.SPECIMN_taken_TIME,
ors.ord_value,
BASE_NAME,
NAME,
reference_unit,
SPECIMN_taken_date
ORDER BY mr_nbr ASC;
Used TOAD to create oracle view and table
What do we do with them?
• Link with Protocol Patient management systems
• Source for screening systems
• Event alerts (admission, lost patient coming in,
pregnancy, auto graded lab AE’s etc)
• Error checking and QA reviews
• Missing data….
• Most output sent as email alerts or shared server
files (excel)
Problems
• Clarity depends on very intensive overnight
processing - Some processes can fail or be
delayed till later in the day
• Daily snapshot, not live
• Use is restricted to advisory systems, we do
not currently do automatic data entry
• Change in database on either end (or the
middle) can cause problems
Going forward
• Migrating towards more directly integrated
systems… but will lose our flexibility to
respond to problems quickly
• Working backwards for error checking and
filtering tools to be in EPIC itself
Lessons learned
• Knowing it can be done is sometimes the key to
getting it done
• Snapshot approach simplifies development
• Shift filtering to your side to make it easier to get
the data
• Operational validation needed
• Advisory systems suggested
• Think big: envision the endpoint before the
conversion or before the project starts