Conversions, Reports, Interfaces for 6.16 Readiness

NMC’s Data Management and Integration PlanChris Giroux, DMIS Manager

NPR to M-AT – 6.07 to 6.1

NPR Application M-AT Application

ABS - Abstracting CAS- Case/Mix Abstracting

ADM-Admissions REG- Registration

BAR- Billing Accounts Receivables

RCG- Revenue Cycle

OR- Operating Room Mgt SUR- Surgical Services

ARM- Authorization Referral Mgt

ARMG- Authorization Referral Mgt (MAT)

SCH-Community Wide Scheduling

CWS- Community Wide Scheduling (MAT)

The Process of Conversions Conversion call with Meditech – 8 months out

◦ Review the process with all parties (Meditech Project Manager, ABS, SCA/ABS, and SUR)

Site establishes conversion teams for each conversion; ABS, BAR, OR, ARM, CWS◦ Typically 2-3 people

Meditech opens a support task for each conversion & groups communicate via task system and weekly meeting (if requested)

MEDITECH Application Specialist by Module have their respective programmers setup their individual Conversion Databases. Ie.)ZCONV.BAR, ZCONV.ABS, then eventually ZCONV.ALL

Teams attend dictionary trainings with MEDITECH & begins build out of dictionaries covered during training and needed for implementation

MEDITECH Specialist provides a listing of dictionaries needed to complete mappings & teams builds maps in MEDITECH ZCONV database to match old values to new

MEDITECH Specialist defines parameters in ZCONV database

MEDITECH Specialist copies dictionaries from TEST database to their respective ZCONV database

Mini File created via extraction routine in OV and moved to Application Server.◦ Each module works on mini conversion files (500 records)

ABS to CASDictionaries to be mapped:

Admission PriorityAdmit SourceAnesthesia TypeArrival ModeAutopsyCharge SubcategoryCoronerCritical Access TypeDeliveryDischarge Disposition*Financial Class*Grouper VersionMarital Status*Newborn Admit SourceNumber FormatPerson (Coder)Query*Race*Registration Type*Patient ClassTissueInsurance*Location*ProjectProvider*Special Care UnitSpecial StudySpecialty

ABS to CAS lessons so far

• Code loads: • Site will need to provide codes (from AMA-CPT & HCPCS) historically, so have

your codes & Meditech only has the last few years of DRG & APC.• In 6.1 the code load is required to be anweb2016.txt File.

• Many errors; think them through• ie) we found errors when mapping had occurred, Meditech researching-

query of VS.TEMP not mapping – requires JIRA• May only map queries that are pertinent to ABS/coding

• Create pdfs of errors for each load for comparison

• For each load, request that Meditech “reinitialize” and “recopy all dictionaries”

• Several demographic errors• Requested an earlier layered testing • MPI load to ZCONV.ALL (pre-staging 6.0 to 6.1)

OR to SUR conversion

For the 6.0 to 6.1 pathway, there exists an appointment conversion program that will convert all scheduled surgical cases from the 6.0 ORM database to 6.1 SUR database.

Before the conversion can take place the dictionaries that exist in 6.0 need to be mapped to the corresponding dictionaries in 6.1.

An overview of the conversion can be found here:

https://customer.meditech.com/en/d/prwsur/otherfiles/60to61pathwaysurconsiderati

OR to SUR mapping Mapping tables can be built as soon as the SUR dictionary build is complete. The mapping tables must be complete prior to running the test conversion in theZCONV ring.

• Maps for Procedure Group/Procedures• Resource Group/Resources• Room Group/Rooms • Maps for AnesthesiaType• Case Type • Facility

The exception report can be run to validate the conversion testing. For example, if a scheduled case cannot be converted due to incorrect mapping, that appointment will print to the exception report so that the problem can be identified and fixed. There is a re-queue routine which can be run after appropriate edits have been made to resend failed appointments.

GO-LIVE: SUR scheduled cases will be converted from the 6.0 ORM database over to the new 6.1 SUR database. The process is very similar to the test conversion process. The exception report can be run to validate the data conversion

BAR to RCG• Decide on how many years of data to convert

NMC chose 7 years it must coincide with ABS

• Meditech provides an extraction/load demo & sets up path to load files.

• Meditech provides a location to drop files –\\NMN-FS5\z$\BARCONV, ran into issue with root permissions

• Run mini files; choose 500 account of the same account status, ie. UB, FB, etc.

• Work through errors & then pull larger files

• BAR dictionary hierarchy: https://customer.meditech.com/en/d/prwbar/pages/bar6iasdicthierarchy61.htm

SCH to CWS• Converting all future Booked, Pending, and Booked Waitlisted

appointments from 6.0 into the ZCONV.ALL ring for testing purposes.

• The conversion itself is run through the UPT Desktop in TEST 6.15 and we can also include OR cases as well as CWS appointments.

• Meditech will be running this utility as it gets closer to Layered Conversion testing to determine accurate timing estimates and help resolve any issues with build prior to the LIVE date.

• On Go Live, CWS Appointment conversion will be run into 6.1 LIVE when the Update and Dictionary Replay has finished (this could be at 4 a.m. potentially).

• Dictionaries mapped: Appointment Group, Appointment Type, Resource Group and Resource.

Mapped in CWS Migration Mapping Routine: Administrative> Community Wide Scheduling> System Management> CWS MigrationDesktop

Develop an overall conversion plan• Have an integrated plan

• Coordinated effort between modules

• Single point person

• Document mappings

Reports – take inventory• Run report of report usage – provided by Acmeware

• Work with users to identify needed custom reports individually

• RW reports need to be rewritten in RD if going from NPR to MAT; ADM (13), ABS (not counted yet), BAR(2), SCH (7)

key reports are facesheet, attestation sheet, wristbands, single label, sheet of labels, census reports

• RW reports to become SQL report from Data Repository (SSRS reports)

• Existing DR reports to be re-written & union to get historical• In particular ADMVisits -> RegAcct_Main; and BAR to RCG

Reports to Assist with the build

Remember to utilize DR capabilities to create and use reporting to assist with the 6.1 build

DR Table changes analysis

Tables used by Acmeware Table used in OneView Table used in nmc_data

DR change description # existing stored procedure effected

Renamed Tables 14

Renamed Columns 48

Deleted Columns andTables

254

New Tables New Columns

7990 1450

Report Usage We organized reports by department for analysis by with the ability to update and assign Report Priorities.

Departmental Stats

We were able to track progress by Department and shift efforts as needed to stay on target.

Reports by StatusMonitoring reports by status assisted with keeping the pulse on the report conversion

Status DashboardTracking overall progress as we approached our go-live target goal.

Conversion Report Management

• Identify report conversion needs

• Include reports outside of the data repository

• Identified clean up opportunities

•Manage and Track progress

Report Conversion

•Recognized need to manage reports

•Lessons learned during conversion process

•Documented functionality needs

•Development of Report Management System

Report Management

Custom Reports

Create a Custom folder on users menu for custom reports

Interfaces

• Have an integrated project plan

• Person to coordinate testing & working with OV

• Think of ALL interfaces, not just those in NMI; 3M

• Test, TEST, TEST!!!