Objectives

1. Objectives • Describe CHCS • Describe the major central repositories that include MTF data • Briefly describe the M2 • Identify common data quality problems • Describe how M2 Standard Reports can be used to manage data quality • Use M2 DQ Standard Reports • Only for attendees of hands-on session

2. The Data’s No Good! And the number of discharges we can recapture is…….. At least I didn’t use it! Why fix it? Who cares if the data are bad! We just used the old dartboard method! Since the data is not good

3. Composite Health Care System • Much longer briefing later in course on CHCS • High level overview in this session! • What is CHCS? • Primary operational system used by MTFs • Used for day-to-day activities within the MTF • Appointing, scheduling, registration, ordering of tests, referrals, etc.. • Importance of CHCS cannot be stressed enough!

4. Composite Health Care System • CHCS is the starting point for nearly all MTF data • Point of original capture • Real-time data • Much of the data in CHCS is captured simply because someone is doing their job • For example, when provider orders a prescription in CHCS; a record of that is kept in the CHCS pharmacy file

5. Composite Health Care System • CHCS has no central repository • Built a very long time ago • 100+ separate systems! • Significantly hampers usefulness of local data • Richness of CHCS data is a definite plus, but must remember that data are only local • Great for production type studies; not enough for person based work

6. Composite Healthcare System (CHCS) Access NCA San Diego Co Springs Tidewater No connectivity between 100+ separate systems! Landstuhl Etc…. Pendleton

7. Example: MTFs on Eisenhower CHCS Host Local CHCS queries only retrieve data for care provided at these MTFs!

8. Example: Inpatient Data Available at EAMC from CHCS Most of the days of care for EAMC area enrollees are not visible in CHCS

9. Composite Health Care System Data Availability • Several options for using CHCS Data: • MUMPS Queries • “Fileman” Queries • CACHE • ICDB • Varies by MTF what can be done • Larger MTFs tend to have more options • Data also available in other central systems

10. CHCS Data Products

11. CHCS & AHLTA AHLTA new capture system Intended to be an electronic health record Replaces (sort of) CHCS Ambulatory Data Module Unlike ADM, AHLTA built to support provider’s activities (i.e. note taking, reviewing test results, etc) Overly complex architecture; system problems are common AHLTA writes data to CHCS, which is the used to create a SADR (Called writeback) Still not used in all clinics

12. FLOW OF SADR MDR SADR file contains ADM & AHLTA information M2 SADR CCE CHCS/ADM Writeback CDR ADM & AHLTA are used to capture ambulatory data APPT AHLTA

13. Use of AHLTA for Outpatient Care 10% of regular visits still not captured in AHLTA Very little usage in ER and Same Day Surgery Centers – more for office based care

14. Clinical Data Mart Clinical Data Mart Enables viewing of some of the more important data from the Clinical Data Repository (AHLTA) Structured database accessible through Web version of Business Objects Primary source of data is CDR (and CHCS indirectly) Also receives nightly file from DEERS Role-based access; no worldwide access available currently Not complete enough for many purposes (Not focus of DQMC for that reason)

15. Expense Accounting System (EAS) Repository • EAS is the tri-Service financial system used at MTFs • EAS is used to create MEPRS data • Full-Time Equivalent Staff (generally via DMHRS) • Workload (via CHCS) • Expense Information (via Service $$ system) • MEPRS codes • Used in all MTF systems • Data Availability: • EAS Repository • MDR/M2

16. Pharmacy Data Transaction Service Repository • Online Drug Utilization Review System • Used by MTFs, Mail Order Contractor and Retail Contractor • Excellent source of information about prescription drug usage • Data Availability: • Through PDTS Business Objects System • MDR/M2 • Reported automatically, when MTF does DUR check

17. MHS Data Repository • “Home-grown” business data warehouse • Developed outside normal IT process • MDR receives and processes data from a wide variety of sources • Data feed management • File Batching • Data Processing • File Storage & Archiving • Preparation of Extracts for Data Marts

18. Basic Data Flow Data sent to MDR 24/7 MDR Processing, File Storage & Limited Access MEPRS MDR Feed Node Batches CHCS Weekly Monthly DEERS Claims M2 1500+ users access in M2 Others

19. Preparation of MDR Files • MDR is the “workhorse” – where most of the processing of data occurs. Generally includes: • Archiving and Storage • Person Identification enhancement • Application of DEERS attributes • Addition of market concepts (i.e. catchment) • Addition of DMISID attributes (i.e. enrollment MTF Service, etc) • Grouping (DRG, APC, etc) • Addition of costs and weights (RVUs, RWPs) • And much, much more……… • Other systems tend to “catch, store and show” • Cleanest, most comprehensive source of data

20. The MHS Mart • The “M2”: • Very popular data mart • Contains a subset of MDR data • Many data files from MTFs + other data, too! • Significant functional involvement in development and maintenance • 1500+ users at all levels in the MHS • Ad-hoc querying or “Standard Reports”

21. Systems to use for Data Quality • No one system will answer all your questions! • Local systems: • Best for real time or near real time management • “How are we doing?” • Corporate systems: • MDR/M2 used for most major initiatives and by local MTFs • Important that data be right there! • M2 Standard Reports are designed to assist with monitoring MTF DQ • “How did we do?”

22. Systems to Use for DQ Mgmt • M2 Reports: • Many reports available • Most resemble or are exactly the required DQMC reports • Some on emerging DQ issues • Easy to use • Need only basic M2 knowledge • Must know your MTF DMISID to use MTF Level Reports • Will demonstrate throughout! • Report documentation is in your notebooks

23. Data Quality Monitoring and Improvement • MTF Data to Review in the context of data quality attributes: • Standard Inpatient Data Records • Standard Ambulatory Data Records • Pharmacy Data Transaction Service • Expense Assignment System (MEPRS) • MTF Lab and Rad

24. Attributes of Data Quality • Completeness • Do I get all of the data that I need? • Timeliness • Is the data I need there when I need it? • Accuracy • Is the data correct, or at least “correct enough”?

25. Completeness

26. Common Data Quality Items • Why do you need complete data?

27. Common Data Quality Items • Why do you need complete data? 340 discharge records lost!

28. Why does it matter? • Missing component of health history for beneficiaries • Less budget at Service level • Less funds for MTFs • Appearance of quality issues • Underestimation of productivity and efficiency • Improper business planning; poor business case analysis

29. Common Data Quality Items • Why can data be incomplete & what can you do about it? • Simple lack of data capture • Incomplete or erroneous transmission of data • Improper processing & handling

30. Lack of Data Capture • Some data are captured during the business process • Often sent off automatically • Example: Appointment file Daily End of Day Processing Periodic standardized data feeds Real-Time Patient Call Real Time Using CHCS to book appt

31. Lack of Data Capture • Data captured during the business process • CHCS tables: • Updated in real time while MTF staff does their jobs • Not generally used beyond local level • Lack of central warehouse makes it difficult • CHCS automated extracts: • Appointment File • Outpatient Lab, Rad and Rx Files • Referral File

32. Lack of Data Capture • Some data are captured because a policy or guidance requires it • Unified Biostatistical Utility (UBU) distributes health care coding policy • Example: SIDR - Inpatient Stays • Example: SADR - Completed outpatient visits and inpatient rounds

33. Lack of Data Capture • Some data are captured because a policy or guidance requires it • More comprehensive set of health care reporting in private sector; not reported = not paid! • MHS decides whether “juice worth squeeze” since budget not entirely claim based • Examples of data not required: Inpatient Surgical CPT Records Ambulance Records

34. Lack of Data Capture • Some data are captured because a policy or guidance requires it • Policy gaps cause some problems analytically • “Lack of Capture”: When policies are not followed – makes analysis harder! • Incentives + Supporting Policy = Best availability of data • Recent improvements

35. Capture Requirements • Worldwide Workload Report • Earliest CHCS product with information about MTF care delivery • Monthly summary workload: • Visits, Days, Dispositions • Year, Month, MTF, MEPRS Code, Patient Category • Historical significance: • Major determinant of payments to contractors in early TRICARE contracts (not today!)

36. Example WWR Data B MEPRS Code (Outpatient): Visits A MEPRS Code (Inpatient): Adm, Disp and Days

37. Capture Requirements • Worldwide Workload Report • WWR is required by all Services for all of their active MTFs • Reports include one month of data • When WWR file is received, it is usually complete • Changes occur at times; but not common • Often called “gold standard”

38. Capture Requirements • Worldwide Workload Report • Used to measure completeness of other MTF workload data sources • Reporting of WWR part of DQMC program • Sent to Service Agencies and then onto MDR MDR PASBA AFMSSA NMIC

39. Capture Requirements • Standard Inpatient Data Record • One coded record per inpatient stay • Roughly 250,000 per year • Contains rich detailed data on each stay • Can identify patient and providers; includes diagnosis, treatment and other administrative data • Significance: • Primary source for most inpatient data needs.

40. Some Sample Data from SIDR • Many more data elements available on SIDR – hundreds of them • MTF DMISID + Register Number (PRN) is the way to identify a unique record

41. Capture Requirements • Standard Inpatient Data Record • MTF Requirement since late 1980s • All inpatient stays must be coded • Stable data feed • Sent to MHS Data Repository / M2 and derivative systems • No inpatient data sent to Clinical Data Repository or CDM

42. Capture Requirements • Standard Inpatient Data Record • Completion of a SIDR requires more effort than completion of WWR • Much more detailed report • Completeness is not usually a problem, though • Well established reporting process

43. Picture of SIDR flow CHCS • SIDRs sent monthly from local CHCS hosts • Assembled into one file and processed in MDR • Sent to M2 CHCS MDR CHCS CHCS M2 CHCS, etc

44. MDR Processing of SIDR • MDR processing includes: • Applying updates and adding new records • Running through DRG Grouper • Adding RWPs • Adding standardized patient information • Adding costs, PPS data • Many, many more things • MDR enhancements are significant • Makes the MDR/M2 SIDR files a very useful choice

45. Completeness of SIDR Data • Required reporting element for DQMC • Measurement: • Number of SIDRs / # dispositions reported in WWR • Expressed as % Complete • Can easily be reviewed using M2 Corporate Document • tma.rm.dq.dcip.rept.comp.rep

46. Step-by-Step Retrieving a Standard Report

47. Select the report you want and click retrieve! • Use report guide in handout

48. Report is already run! • Contains monthly comparisons of inpatient workload data • All you have to do is look at it! • Service Summary and MTF Detail

49. No obvious holes!

50. Capture Requirements • Standard Ambulatory Data Record • Record of (some) provider work • One coded record per outpatient visit, telephone consult , and inpatient round • No requirement for inpatient surgery SADRs • Roughly 30 million per year • Can identify patient and providers; includes diagnosis, treatment and other administrative data • Significance: • Primary source for most ambulatory data needs.