640 likes | 773 Views
Functional Changes in MDR and M2. Wendy Funk, Kennell and Associates wfunk@kennellinc.com. Functional Changes in MDR/M2. 1)Context: MDR and M2 are two of the most important systems used by MHS analysts today.
E N D
Functional Changes in MDR and M2 Wendy Funk, Kennell and Associates wfunk@kennellinc.com
Functional Changes in MDR/M2 • 1)Context: MDR and M2 are two of the most important systems used by MHS analysts today. • 2)Purpose: This presentation will updates users on changes in these systems that have occurred recently or are about to occur. • 3)Outcome: After attending this session, participants will meet the objectives described on the next slide. FOR OFFICIAL USE ONLY
Functional Changes in M2 • Objectives: • Characterize new features currently available in M2 BOXI • Describe the M2 Appointment Table • Describe the direct care dental data • List the sources of data in the purchased care dental table • Characterize the types of deployment data in M2 • Describe data type specific changes • Describe the CDR Data Retention Project • List changes that are upcoming.
Functional Changes in M2 • M2 switched to a newer version of software this year • Older version of M2 was no longer supported by Business Objects • There was a desire by some to change to a Web-based tool. • The M2 FPG voted that the Web version of M2 did not meet functional requirements • So DHSS deployed a Web-tool (WebI) and the Desktop version of BOXI called “DeskI” FOR OFFICIAL USE ONLY
Functional Changes in M2 • DeskI is very similar to Business Objects 5.1.7 • Querying works the same way • Differences include • Method of logging on • Retrieving and working with corporate reports • Sending and receiving reports • Ability to use the results of a query as a subquery FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • BO 5.1.7 performed subqueries • Users could use an “in list” command and then build a new query to retrieve data from M2. • Now, users can use an existing query in the “in list” condition. • Consider the following: • You want to write a report to include only procedure code descriptions that are in the main query, so that you can make a detail object out of them. FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • Main Query: • Radiology Procedures at Camp Pendleton in FY 2011. • Insert a report to get descriptions FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • When building the procedure code description report, we get an option “Select Query Results” FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • After pressing “Select Subquery Results” • Select Query 1 FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • After Selecting Query 1, M2 provides a list of elements, and the user select which one to use as a filter. • The advantage here is that you only get codes that you want returned. There will be no extraneous rows after creating the detail associated with procedure code. FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • Final Look: Right before hitting run FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery • Final Steps: • Link procedure codes FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery Create a detail object Use slice and dice to bring into report. FOR OFFICIAL USE ONLY
Using Results from a Query in a Subquery FOR OFFICIAL USE ONLY
Functional Changes in M2 • WebI is “sort of” similar to Business Objects 5.1.7 • Querying is very similar • No slice and dice, but most functionality still available • Significant differences in handling of data (i.e. saving, etc) • Some functionality that is not available in WebI: • User – Defined Objects • Use of local data • Less flexibility in saving files FOR OFFICIAL USE ONLY
Functional Changes in M2 • There are some new features in BOXI (both WebI and DeskI) • Infoview Web Portal. • Ability to save data to the server rather than locally (good for PHI/PII) • Ability to develop dashboards and other customized views • Some issues with BOXI • Significant issues with run-times. Improvements lately! • Browser updates can cause problems. FOR OFFICIAL USE ONLY
New Publishing Feature of BOXI Navy Analytics Newsletters FOR OFFICIAL USE ONLY
Navy Analytics Newsletter • Navy BUMED sponsored newsletter for analysts and other users of data. • 8 are published per year. • Topics include: FOR OFFICIAL USE ONLY
New Publishing Feature of BOXI • Corporate Reports Handbook • See Conference Website for slides on Corporate Reports FOR OFFICIAL USE ONLY
Functional Changes in M2 • Business Objects has told DoD that they will cease to support DeskI at some point in the future. • DHSS would like to switch to only WebI soon. • Business Objects is working to close the “functionality gap” between WebI and DeskI • DHCAPE will approve the switch to WebI when the gap is closed. FOR OFFICIAL USE ONLY
Recent Changes FOR OFFICIAL USE ONLY
New Data Tables • Appointment Table: • Direct care appointments only • Contains a record for each appointment in CHCS. • Includes cancellations, left w/o being seen, etc. • Prepared from the TRICARE Operations Center (TOC) data feeds that are used for reporting of access to care measures. • Populated from FY 2005+ like other data tables. • Updated weekly. • Used to prepare “inferred encounters” also.
New Data Tables • Ideas for using this new table: • Can be looked at to track no-show rates • Can be used to look at historical compliance with access to care standards. Can trend from FY 2005+ • Can be used to track compliance with access standards for specific populations that are not separately identified by the TOC. • Can be used to look at scheduled appointment times, compared with E&M codes recorded in CAPER. • Can be used to determine if particular specialties or PCMs are having access to care issues.
Unused Appointments at One Navy MTF in One FM (Top Clinics) FOR OFFICIAL USE ONLY
Tracking Compliance with Access Standards • Compare length of time from date appointment made, to date of appointment. • Use “Length of Time Until Appointment” • M2 won’t let you calculate yourself. FOR OFFICIAL USE ONLY
Tracking Compliance with Access Standards • Retrieve appointment type, length of time until appointment. • Used only Specialty Appointments at one MTF in one month • Created a local variable to group lengths of time. FOR OFFICIAL USE ONLY
Tracking Compliance with Access Standards Met the Access to Care Standard for Specialty Appointments 94% of the time. FOR OFFICIAL USE ONLY
Tracking Compliance with Access Standards • One MTF, One Month • Number of Appts outside the access standard by provider. FOR OFFICIAL USE ONLY
New Data Tables • Direct Care Dental: • New table, as of November 2011. • Detailed encounter data for dental care. • Generally contains Army and Air Force data, for now anyway (exception is National Military Medical Center Walter Reed) • This is because Navy doesn’t generally capture dental data (DENCAS) in sufficient detail - person level procedure data is not generally captured in the Navy. • There are plans later, to add dental weighted values to the MEPRS table, which will be for all three Services.
Dental Encounters in M2 by DMISID Military Service Navy Workload is entirely the new Walter Reed FOR OFFICIAL USE ONLY
Dental Encounters in M2 Walter Reed and Bethesda FOR OFFICIAL USE ONLY
Dental Encounters For Navy Beneficiaries by Other Services FOR OFFICIAL USE ONLY
Global Changes • Addition of Deployment Information • Source of deployment information is DMDC. • Deployment related data elements have been appended to all detail data tables in M2. • Ever Deployed Flag (OCO): Indicates whether the beneficiary had been deployed as of the reporting date in the record. • OCO Deployed Flag: Indicates if the beneficiary is currently in deployed status as of the reporting date in the record. • Particularly useful with population data because deployed cohorts aren’t generally receiving care through the DHP. This allows you to take the deployed out of denominators when calculating things like PMPM Costs, or Utilization/Enrollee.
Global Changes • Cumulative OCO Deployed Days: Indicates how many days the member had been deployed in total, since 9/11/2011. • Many studies has shown this to be associated with poor outcomes. • Days Since Most Recent Deployment: • To assist in finding beneficiaries who may be vulnerable due to a recent return. • Could also be used to track who needs a Post Deployment Health Re-Assessment.
Using M2 Deployment Flags % of Active Duty OCO Deployed at Beginning of FY12 FOR OFFICIAL USE ONLY
Using M2 Deployment Flags • Navy created a special DMISID to be used for enrollments of deployed service members, rather than keeping the member enrolled at their home port. • The top enrollment site for Navy/Marines deployed is “6992” – Active Duty Navy with 33K enrollees • Fort Bragg has 11K enrollees that were deployed at the beginning of FY 2012. Fort Hood had 20K. • Wreaks havoc on analysts use of the data b/c the people being called “enrolled” don’t generally have an opportunity to receive health care from the DHP. FOR OFFICIAL USE ONLY
Using M2 Deployment Flags % of Army Enrollees at MTFs who are deployed at the time the enrollment was reported. FOR OFFICIAL USE ONLY
Using M2 Deployment Flags Navy MTFs with the Largest Deployed Population at Beginning of FY 2012 FOR OFFICIAL USE ONLY
Using M2 Deployment Flags % of Navy AD Workload for Members who have been deployed -- Top 5 Clinics. FOR OFFICIAL USE ONLY
Using M2 Deployment Flags Admissions for Members Deployed at the Time of Admission – Most Frequent MTFs FOR OFFICIAL USE ONLY
Global Changes • Transition of Tnex to T3 • Complicated contract changes occurring with the TRICARE MCS Contracts • Numerous awards / protests / appeals, etc… • Decided to put both T3 and Tnex Regions into M2. • Tnex region (HSSC Region) has not changed. • However, the old region data elements (populated with 01, 02, 03, etc) are now filled with the T3 region. • Gives users the flexibility to report either way. • Historical regions have been removed from M2 altogether.
Data-Type Specific Changes MTFs with the most dispositions for Navy Afloat Service Members • Standard Inpatient Data Record: • Renamed Service Date to Discharge Date: • Technically, this is a disposition date. • Added Sponsor Service, Aggregate: • Can identify Navy Afloat with this. • Added Diagnosis 9 – Diagnosis 20 • Added Procedure 9 – Procedure 20.
Data-Type Specific Changes MS-DRGs in the Network for Navy Afloat Service Members • TED-Institutional: • Added diagnosis codes 9-11 • Total of 12 Dx fields now. • Added Sponsor Service, Aggregate: • Can identify Navy Afloat with this. • TED-Non Institutional: • Added Sponsor Service, Aggregate: • Can identify Navy Afloat with this
Data-Type Specific Changes • Ancillary (MTF Lab and Rad): • Renamed related record ID to be appointment record ID. • Added inpatient record ID, however this element seems to have some issues. • (Ancillary cost data seems highly suspect at this time). • Referral: • Added appointment date and date appointment made. • Can be used to track access standards. • (Math issues with dates) • Renamed referral FY and referral FM to FY and FM, respectively. • Pharmacy (PDTS): • Changed sponsor service, common to sponsor service, aggregate • Renamed NPI Type 2 to Pharmacy NPI.
Data-Type Specific Changes • Users were encouraged to switch from using SADR for professional encounter reporting, to using CAPER. • Changes were made to the CAPER data in M2 to make it more user friendly. • Renamed data elements for consistency purposes. • Formatted diagnosis codes to be consistent with the reference tables and other data files. • Dropped several RVU elements: • Examples: Individual Work RVU, Simple Work and PE RVU • Renamed PE RVU (13) to PE RVU, Non-Provider Affected (13) • Dropped APC Aggregate Weight (5) • Hid PPS Earnings related data fields because they were not properly maintained (more later)
Data-Type Specific Changes • CAPER: • New RVU elements for direct care. • New aggregate measures, provider specific measures for direct care only. • All new elements have work, PE and total components • Many of the old RVU elements are still available also. • No changes were made to purchased care. • As a result, still best to compare enhanced RVUs (13) in CAPER with enhanced RVUs in TEDs. • But new fields are helpful for direct care only type work.!
CAPER RVUs • CAPER: • PPS and Business Plans use the new Provider Aggregate RVU (PAR). • Edit logic is now incorporated into RVU assignment! Makes it difficult to track coding issues. • PAR incorporates all 13 Procedure Codes. • Initially, only 5 procedure codes were considered with enhanced RVUs. For most records, this will have no impact but for some, there will be positive gain as a result. • PAR incorporates Procedure Code Modifiers: • Previously, only lab/rad modifiers and some DME were used. In the Provider Aggregate RVU, the following modifiers are considered. • Bilateral, Unrelated E&M, discontinued services, unusual services • Incorporates Discounting: • 100% credit for highest weight procedure, 50% credit for all others. • Whether a procedure’s RVU is discounted depends on the CMS Payment Status Indicator for the code.
Data-Type Specific Changes • CAPER: • Treatment of Nurse Only workload is different with PAR • Nurse only workload has always been credited in M2, but was not used in PPS in 2011. • In 2012, the PAR will have the nurse logic built in. • Most nurse workload won’t count but there are some procedures that will (i.e. flu shots) • These can be identified in M2 in the CPT/HCPCS reference table.
Data-Type Specific Changes • CAPER: • Provider Adjustments are made with PAR • With enhanced RVUs, credit was only given for the primary provider. • In PAR, providers receive credit for all care they participate in, though not always at full credit. • Nurses only receive credit for some specific CPT/HCPCS codes.
Data-Type Specific Changes • CAPER: • Provider (appointment & add’l providers 1 – 4) • Up to 5 providers • Proc 1 RVU (NPA) – Proc 12 RVU (NPA) • Up to 3 E&M codes and 10 procedures • NPA = Non-Provider Affected • There were also additional procedure specific and provider specific RVU elements added to M2 • These are difficult to use because M2 has multiple procedures and providers per CAPER.