mhs data overview m2 foundations course n.
Skip this Video
Loading SlideShow in 5 Seconds..
MHS Data Overview M2 Foundations Course PowerPoint Presentation
Download Presentation
MHS Data Overview M2 Foundations Course

MHS Data Overview M2 Foundations Course

317 Views Download Presentation
Download Presentation

MHS Data Overview M2 Foundations Course

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. MHS Data OverviewM2 Foundations Course

  2. MHS Data Overview • 1)Context: MDR is the primary source of management data used in the MHS. • 2)Purpose: This presentation will familiarize users with the MDR project • 3)Outcome: After attending this session, participants will meet the objectives described on the next slide. FOR OFFICIAL USE ONLY

  3. Objectives • Attendees can: • Describe the major data collection systems in the MHS. • Describe data feeds from these systems to central repositories. • Describe the MDR and its role in feeding MHS data marts. • Identify key strengths of using MDR-based data vs. local data. FOR OFFICIAL USE ONLY

  4. HIPAA Note • Examples in this presentation are based on live data. • However, some items have been changed to preserve the privacy of patients! • (Nothing that changes the overall gist of what is being displayed, however) FOR OFFICIAL USE ONLY

  5. Good News, Bad News • Good news: • The MHS has made significant advances in automation systems • We have tons of data that other health systems and providers wish for! • Bad news: • Some quality issues with the data • Very cumbersome development process • This presentation will highlight available data and discuss strengths and weaknesses along the way! FOR OFFICIAL USE ONLY

  6. Kinds of Data The MHS Collects Centrally And more and more and more FOR OFFICIAL USE ONLY

  7. Process for Making Data Available • Data are collected through a variety of systems in the MHS. • Historically, the MHS operated many duplicate repositories with similar data. • These systems would almost never agree so that users were left stuck with “what’s the right answer?” • In CY 1999-2000, the MHS Data Repository was built. FOR OFFICIAL USE ONLY

  8. Data CEIS IDB Mart (edit checks M include parser & logical edits) T F AIR Force C (uses AFVAL edits) H RCMAS Legacy RCMAS Army C V1 SAS V2 DMIS (uses PASBA S Processor edits) Navy DMIS-SS (none, may use PASBA edits) Inpatient Record Data Flow (Oct 98) FOR OFFICIAL USE ONLY

  9. Until 6/30/99 Data CEIS IDB Mart (edit checks IDBR M include parser & (min edits) logical edits) Feed Node RPU RLP RLP T SAS (min (min F edits) edits) EDW EDW Stars AIR Force (data transformed ETL C (uses VRI to FAM-D standard) AFVAL edits) H RCMAS Legacy RCMAS C V1 SAS Army V2 DMIS (uses PASBA S Processor edits) Navy ARS DMIS-SS PASBA (none, may use PASBA edits) Inpatient Record Flow (Apr 99) FOR OFFICIAL USE ONLY

  10. Feed Node M2 Other Data Marts MDR Inpatient Record Flow (Today) M T F C H C S Simplicity………. FOR OFFICIAL USE ONLY

  11. MHS Data Repository • A ‘data warehouse’ containing MHS data • Most popular system you never heard of! • Most comprehensive source of MHS data available • Receives data from all MTFs, DEERS, Private Sector Claims Data, and many other sources. • Data are processed to create new data elements, and to enhance the quality of data received. • Constantly evolving to include new and relevant data. • Serves as the primary source for M2 and other data marts. • Also provides data to the Services for incorporation into Service-specific systems. FOR OFFICIAL USE ONLY

  12. MHS Data Repository • Many data warehouses simply display source data as provided. • The MDR always stores original values that are received from sources, • But, when possible, programs have been written to add new variables to correct source system errors or to standardize data amongst sources. • Corrections are not always possible! FOR OFFICIAL USE ONLY

  13. Routine MDR Enhancements Person Identification Enhancement: Many systems collect partial person identifying information Sometimes this is just by design, sometimes because some identifiers are unknown or do not exist at the time records need to be submitted. MDR repeatedly applies a “Master Person Index” file to add missing information to its records. Allows for timing differences and omissions among disparate sources. Ensures a consistent identification of patients, regardless of source of data. FOR OFFICIAL USE ONLY

  14. Example of MPI Application After MDR Processing As received FOR OFFICIAL USE ONLY

  15. MHS Data Repository • After correction of person identifiers, demographic and enrollment information is appended. • Generally represents status on the begin date of care. • For files that do not represent health care, demographic or enrollment information may represent different concepts. Consult data dictionaries for more detail. • Status information comes from DEERS, generally. • Information is updated monthly (for 6 months) to enable late-arriving changes in status of beneficiaries (called retroactive processing) • May disagree with local source data but is considered legally accurate. FOR OFFICIAL USE ONLY

  16. Example After MDR Processing As received . Person-identifier was not available when MTF submitted original record. Patient was also not enrolled at that time. FOR OFFICIAL USE ONLY

  17. Application of Organizational Hierarchies Source data will often come in with DMIS IDs to represent treatment locations, enrollment sites, or geographic areas. MDR applies a consistent hierarchical mapping to allow users at all levels to easily extract data Branch of Service, Parent DMIS ID, Major Command, Region, Multi-Service Market Area, etc. Users choose which level meets their business questions the best! MDR Enhancements FOR OFFICIAL USE ONLY

  18. MDR Enhancements Application of Market Areas Source data often arrives with zip codes Residence zip vs. point of service zip Zip codes are cumbersome to analyze! MDR applies a standard set of market area definitions to each incoming record Allows for convenient extraction of ‘local’ data Catchment, PRISM, MTF Service Areas, Multi-Service Market Areas, etc FOR OFFICIAL USE ONLY


  20. MDR Enhancements Grouping of health care records into similar categories: MS-DRGs: Groupings of inpatient data into categories that are similar in terms of clinical aspects and expected hospital resource utilization. MDC: Groupings of inpatient data into categories based on primary diagnosis. APC: Groupings of ambulatory services into categories that are similar in terms of clinical aspects and expected hospital resource utilization. Product Lines; Groupings of direct and purchased care data, determined by Health Affairs. FOR OFFICIAL USE ONLY

  21. Application of Weights and Costs Workload weights are added in MDR processing Important to understand the value of care. Relative Value Units (RVUs), Ambulatory Patient Classification Weights (APC) and Relative Weighted Products (RWPs) Direct Care Estimated Full and Variable Costs are also added. These are the elements used in M2. MDR Enhancements FOR OFFICIAL USE ONLY

  22. Application of Linkages in Direct Care Records Records that originate from CHCS generally have imbedded linkages in them to enable tracking of provider’s orders. For pharmacy, laboratory, radiology and referrals, the MDR adds information about who ordered a particular service. CAPER: MDR Enhancements MTF Labs/Rads: FOR OFFICIAL USE ONLY

  23. Application of Linkages in Purchased Care Records Currently, acute care episodes have been built for purchased care. Enables users to tie hospital and professional bills together. Coming soon for Same Day Surgery as well. TED-I MDR Enhancements Associated Professional Records: FOR OFFICIAL USE ONLY

  24. MDR Enhancements • Convenience fields: • Elements such as Calendar Year, Calendar Month, Fiscal Year, Fiscal Month. • Things that are thought be commonly needed. • There are many other data-type specific enhancements. • Will discuss some of these as we go through the various data types in M2. FOR OFFICIAL USE ONLY

  25. Basic Data Flow Data sent to MDR 24/7 MDR File Storage & Limited Access TED MDR Feed Node Batches CHCS/AHLTA Weekly Monthly DEERS PDTS M2 and Data Marts User Access in Data Marts Others FOR OFFICIAL USE ONLY

  26. Survey of Available Data in M2 FOR OFFICIAL USE ONLY


  28. Person Data • There are two systems focused on person data: • Beneficiary data – • DMDC/DEERS • Not operated by the MHS • Contains detailed data about sponsors and their beneficiaries • Staffing data – • DMHRS • Contains detailed information about staff who work at MTFs. • Not in M2. Will be discussed later in “Other Data” Session. FOR OFFICIAL USE ONLY

  29. Beneficiary Data • DMDC/DEERS: • Operates DoD personnel systems. • Keeps track of active duty, retirees, family members and others with DoD relationships (i.e. civilians, contractors). • Is the legal “system of record” for MHS benefits. • Sophisticated data systems that interact with the MHS and others on a real-time basis. • Update transactions, DEERS Eligibility checks, enrollments into TRICARE, etc. FOR OFFICIAL USE ONLY

  30. Beneficiary Data Data in DEERS • Person Identifiers: Name, SSN, DEERS Person ID • Sponsor Status (Active Duty, Retired, etc.) • Relationship to Sponsor • Sponsor Service, Rank, Unit, Occupation • Enrollment Location (not Medical Home), Primary Care Manager • Geographic Data • Medicare and Other Health Insurance Information, • Etc. FOR OFFICIAL USE ONLY

  31. Beneficiary Data • DEERS maintains multiple records per person, when needed. Only one is deemed “Primary” by the MHS. • Example: Jane and Joe are married. Jane is on Active Duty, Joe is a Reservist. • Joe was activated in 2005/2006, and again in 2011/2012 Joe’s data between 2005/2006 and Oct 14, 2011 Joe’s data beginning Oct 15, 2011 FOR OFFICIAL USE ONLY

  32. DEERS Eligibility Checks • DEERS Eligibility Checks: • Transaction that goes between DEERS and a direct care MTF or purchased care payor that establishes a beneficiary’s eligibility and coverage. • At MTFs, used to determine priority for access to care. • In purchased care, determines how a claim is paid. • Results in an automatic download of data from DEERS to the requestor. • Local systems are not routinely updated by DEERS except through the eligibility check or during an enrollment transaction. • This means local data can be stale! FOR OFFICIAL USE ONLY

  33. DEERS Enrollment Transactions • DEERS • Operates the DEERS Online Enrollment System (DOES). • Used to conduct TRICARE Enrollment activities. • Legal system of record for TRICARE Enrollments. • Enrollment, Disenrollment, Address Updates and Other Health Insurance Updates • An enrollment in DOES triggers a “reciprocal disenrollment”. FOR OFFICIAL USE ONLY

  34. Patient Information Transfer Errors • The process for updating data ensures that: • Enrollees and all other patients being actively treated have current DEERS data in local system • Those not being treated actively will not have good local demographic data! • “PIT Error” is the term used to describe an error in DEERS information transfer. • MTFs that do not take care of PIT errors will have bad local data! FOR OFFICIAL USE ONLY

  35. DEERS Data to the MHS • DEERS Monthly Data Feed (VM-6): • Detailed monthly data file from DEERS indicating beneficiary status on the first of the reported month. • Does not include DoD contractors or civilians. • Contains multiple records per person if needed. • Some people call this file the “PITE” (Point in Time Extract) • Is processed by TMA, made available in M2. • Processing is significant! FOR OFFICIAL USE ONLY

  36. DEERS VM-6 Processing • There are many reasons why DEERS data should be processed prior to use: • It contains more than one record per person. Most people don’t need or want data about ineligibles. TMA flags each record as “primary” and “eligible” or not. • It contains start and stop dates for many pieces of information. These must be applied to get a correct answer! TMA applies the dates for M2 and removes values if expired. • DEERS does not always have the correct status at the time it provides its extracts. TMA updates the data received from DEERS. (Think newborns). FOR OFFICIAL USE ONLY

  37. DEERS Data • Strengths: • Vetting occurs when DEERS data are updated. Must provide official documentation. • TMA-processed DEERS data is the cleanest source for beneficiary status. • Weaknesses: • 1st of the month snapshot. Not real-time or even near real-time. • Beneficiaries are not always diligent about keeping DEERS data up to date. DEERS cannot force a beneficiary to update their information! • Deaths are not always reported in a timely manner, or at all! • Some types of errors can be difficult to fix. FOR OFFICIAL USE ONLY

  38. DEERS Files in M2 • DEERS Eligibility: • All records in these file represent eligible beneficiaries. If person has more than one reason for eligibility, only counted once. • DEERS Person Detail: • Monthly list of person’s eligible; FY06+ • Contains significant demographic and service related data. • (Most robust of all files) • DEERS Population Summary and DEERS Longitudinal Eligibility FOR OFFICIAL USE ONLY

  39. Navy Eligible Population Profile • All data are from M2 DEERS Population Summary and represent December 2011. • Navy/Marine Sponsored patients represent a third of the Active Duty Population FOR OFFICIAL USE ONLY

  40. Eligible Population – Trend • All data are from M2 DEERS Population Summary FOR OFFICIAL USE ONLY

  41. Navy and Marine Population • All data are from M2 DEERS Population Summary and represent December 2011. FOR OFFICIAL USE ONLY

  42. DEERS Files in M2 • DEERS Relationships • Is a subset of the DEERS Person Detail, but with fewer data fields. • All records in these file represent beneficiaries in enrollment programs, or active duty service members. • Each member is only counted once. • DEERS Relationship Detail • Monthly list of persons enrolled or active duty; FY06+ • Contains more limited detail than the DPD. • DPD also contains information about enrollment so that if you need data about enrollees that’s not in the relationship data, you can use DPD. • DEERS Relationship Summary. FOR OFFICIAL USE ONLY

  43. Prime Enrollment Trend by Service of Enrolling MTF One of these lines doesn’t look like the others! FOR OFFICIAL USE ONLY Source: M2 Relationship Summary

  44. Navy Enrollment MTFs 6 Parent MTFs represent half of Prime Enrollment at Navy MTFs FOR OFFICIAL USE ONLY Source: M2 Relationship Summary

  45. TRICARE Plus Enrollees at Navy MTFs 84% of Navy MTF T-Plus Enrollees are also TFL FOR OFFICIAL USE ONLY Source: M2 Relationship Summary

  46. DMDC Deployment Data • DMDC also provides a monthly file that describes OCO deployments • Contingency Tracking System • This does not come from the DEERS Section of DMDC (which deals with peacetime benefits). • Since 9/11/2001, list of all members who have deployed, along with their deployment start and stop dates. • New data feed. Added to M2 recently. • Users cannot see the deployment roster, but can query other tables to get deployment flags. FOR OFFICIAL USE ONLY

  47. Top DMISIDs with Navy/Marine AD Enrollees Deployed Source: M2 Relationship Summary FOR OFFICIAL USE ONLY

  48. Direct Care Health Care Data FOR OFFICIAL USE ONLY

  49. Direct Care Health Care Data • There are many sources of direct care health care data • Most of the health data that analysts use in the MHS comes from each local site’s Composite Health Care System (CHCS) • Some data also comes from the newer (partial) electronic health record system (AHLTA) • MTFs also provide data to the Medical Expense and Performance Reporting System (MEPRS). FOR OFFICIAL USE ONLY

  50. Composite Health Care System and AHLTA FOR OFFICIAL USE ONLY