Getting Data after EPIC

Robert Morrell, MBASystems 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