Getting Data after EPIC
description
Transcript of Getting Data after EPIC
![Page 1: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/1.jpg)
Getting Data after EPIC
Robert Morrell, MBASystems Manager
Comprehensive Cancer Center of Wake Forest University
![Page 2: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/2.jpg)
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
![Page 3: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/3.jpg)
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
![Page 4: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/4.jpg)
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)
![Page 5: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/5.jpg)
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
![Page 6: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/6.jpg)
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
![Page 7: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/7.jpg)
![Page 8: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/8.jpg)
![Page 9: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/9.jpg)
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
![Page 10: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/10.jpg)
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)
![Page 11: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/11.jpg)
![Page 12: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/12.jpg)
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
![Page 13: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/13.jpg)
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
![Page 14: Getting Data after EPIC](https://reader036.fdocuments.net/reader036/viewer/2022062222/5681642e550346895dd5f636/html5/thumbnails/14.jpg)
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