1 / 14

Getting Data after EPIC

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

casey-mcmahon
Télécharger la présentation

Getting Data after EPIC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Getting Data after EPIC Robert Morrell, MBA Systems Manager Comprehensive Cancer Center of Wake Forest University

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

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

  4. 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)

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

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

  7. SELECT /* PARALLEL */ PE.PAT_MRN_ID mr_nbr, ors.result_timeordr_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

  8. 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)

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

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

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

More Related