Section_17_Treatment_Suites_Legacy_version_20140106.doc

Requirements Specification Document (LEGACY DRAFT)

Treatment Suites (Section 17)

Central Bill Process

Treatment Suites (PWS Section 17) Requirements Specifications Document

(LEGACY DRAFT)

Prepared for:

U.S. Department of Labor Office of Worker’s Compensation Programs

Revision History:

SPECIAL NOTICE: This document is a legacy draft requirements specification document developed between 2011 and 2012. As outlined in the Performance Work Statement, the Contractor will be required to review this RSD and make appropriate updates wherever necessary. (Please refer to PWS R0052 for more details.)

Table of Contents Treatment Suites – DFEC

61.1 Treatment Suites Overview – DFEC

61.2 Treatment Suites Business Process Description – DFEC

61.2.1 Web Service

61.2.2 Treatment Suite Tools

71.2.2.1 Builder and Viewer Databases

71.2.3 Treatment Suite Maintenance

81.2.3.1 Reference Files

81.2.4 Treatment Suites Functionality

91.2.4.1 Authorizations

91.2.4.2 CBP Bill Adjudication

101.2.4.3 Eligibility Inquiry

101.2.5 Treatment Suite Logic

111.2.5.1

111.2.5.2

111.2.5.3 Bill Adjudication

111.2.5.3.1 Pre-Process to Identify Exception Conditions

141.2.5.3.2

HCFA-1500

141.2.5.3.3 Outpatient Bills

151.2.5.3.4 Inpatient Bills

151.2.5.3.5 Pharmacy POS Bills

161.2.5.3.6 Authorization Level Exception

171.3 Treatment Suites Business Process Flows – DFEC

181.3.1 Treatment Suite Pre-Processing Workflow

191.3.2 Prompt Pay Pre-Processing Workflow

201.3.3 CA-16 Pre-Processing Workflow

211.3.4 Short Form Closure Pre-Processing Workflow

221.3.5

999.98 Pre-Processing Workflow

231.3.6 HCFA-1500 Treatment Suite Workflow

241.3.7 Outpatient Treatment Suite Workflow

251.3.8 Inpatient Treatment Suite Workflow

261.3.9 Pharmacy Treatment Suite Workflow

271.3.10 Authorization Request Treatment Suite Workflow

Treatment Suites –DEEOIC

282.1 Treatment Suites Overview –DEEOIC

282.2 Treatment Suites Business Process Description –DEEOIC

282.2.1 Service

292.2.2

292.2.2.1

292.2.3

302.2.3.1

302.2.4

312.2.4.1

312.2.4.2

322.2.4.3

322.2.5

332.2.5.1

332.2.5.2

332.2.5.3

332.2.5.3.1 Pre-Process to Identify Exception Conditions

342.2.5.3.2

342.2.5.3.3

352.2.5.3.4

352.2.5.3.5

362.2.5.3.6

372.3 Treatment Suites Business Process Flows –DEEOIC

382.3.1

392.3.2

402.3.3 Inpatient Treatment Suite Workflow

412.3.4

422.3.5 Authorization Request Treatment Suite Workflow

Treatment Suites – DCMWC

433.1 Treatment Suites Overview – DCMWC

433.2 Treatment Suites Business Process Description – DCMWC

433.2.1 Treatment Suites Service

443.2.2

443.2.2.1

453.2.3

453.2.3.1

463.2.4

463.2.4.1

463.2.4.2

473.2.4.3

473.2.5

483.2.5.1

483.2.5.2

483.2.5.2.1

483.2.5.2.2

493.2.5.2.3

493.2.5.2.4

503.2.5.2.5

513.3 Treatment Suites Business Process Flows – DCMWC

523.3.1

533.3.2

543.3.3

Treatment Suites Business Requirements

554.1 Functional Requirements

564.2 Business Rules

Treatment Suites Supporting Functional Components

715.1 Initial Data Migration

715.2 Interfaces

735.3 Reports

745.4 Letters

Constraints

756.1 Assumptions

756.2 Dependencies

756.3 Issues/Open Items

Appendices

767.1 Terms & Definitions

1 Treatment Suites – DFEC

1.1 Treatment Suites Overview – DFEC

Treatment Suites processing is an automated procedure designed to ensure that billed services submitted to OWCP for payment are appropriate and authorized for the claimant’s accepted condition. Built to support Government medical policies and guidelines for each OWCP program (DFEC, DCMWC, DDEEOIC), Treatment Suites consists of diagnosis codes linked to medical procedures, medications and other services typically included in the treatment for a diagnosed condition. Incoming bills are subjected to Treatment Suites edits implemented for each OWCP program, based on the accepted condition identified for a claimant and the services included in its Treatment Suite. Essentially, the existence of a billed service in the Treatment Suite of the accepted condition dictates whether a bill continues through payment processing or is denied.

Treatment Suites functionality plays a critical role in various areas of the CBP solution and is key to consistent, accurate decisions throughout the process:

· Both on-line and phone inquiry processes access Treatment Suites to verify that a claimant is eligible for a specific treatment

· Authorization requests are approved based on the authorization level recorded for each procedure / service in a Treatment Suite.

· Bills are validated against Treatment Suites for Pharmacy and Medical bills, both to ensure that the service billed is valid and to confirm that required pre-authorizations exist.

Treatment Suites is an existing feature of the current OWCP process, and its components will be fully supported with the implementation of the CBP solution:

· The Treatment Suite Builder tool will be used for maintenance to the data housed in Treatment Suites

· Updates to Treatment Suite data will be performed per government approved processes by medical personnel specifically identified with that responsibility

· The Viewer tool will be available for viewing and searching Treatment Suite data by all designated Government and Contractor personnel

· All applications accessing Treatment Suites as part of production processes will access the same set of data

1.2 Treatment Suites Business Process Description – DFEC

1.2.1 Web Service

A centralized Treatment Suite process is critical to providing consistency and accuracy in the CBP system, designed to eliminate billing errors and inappropriate payments of services.

1.2.2 Treatment Suite Tools

The Government-provided Treatment Suite Builder / Viewer tool is the primary instrument that will be used to implement, view, and maintain the Treatment Suites data. The Government has supplied the source code and database requirements to stand up the application. They have also provided current Treatment Suite data (i.e. ICD 9/10, CPT, HCPCS, TC, GCN and RCC) from their legacy system, which will be updated as needed to reflect all required modifications prior to go-live.

Both the Builder and Viewer applications will be accessible through the CBP Portal w/single sign-on. Access to the Builder will be controlled by strict security procedures. Only Treatment Suite Nurses and limited authorized personnel will be granted connection to the update functions that the Treatment Suite Builder provides. Access to the Viewer will be permitted for a much larger audience of designated Contractor and Government personnel in "view only" mode.

The Builder/Viewer tools are very similar in appearance, presented as a GUI interface to the user. The primary difference between the applications is that the Viewer is read-only and defaults to display the results of the selection entered, while the Builder allows the user to create a new Treatment Suite or group/subgroup or update/delete information in an existing Treatment Suite or group/subgroup.

1.2.2.1 Builder and Viewer Databases

The CBP system is required to maintain separate databases to support the Builder and Viewer tools. The architecture will be designed to allow maintenance functions to the Treatment Suite data in one environment, while at the same time ensuring that all areas of the production system are accessing identical up-to-date information in a another environment .

Treatment Suite data accessed at the production level will be consistent across all points of access:

· In the Treatment Suite Viewer, used for inquiries as needed

· Calls to Treatment Suite from the medical bill process for Medical Bills and Authorizations

· Calls to Treatment Suites from the pharmacy bill process for Pharmacy bills

· Calls to Treatment Suites for inquiries from IVR, Web Portal, & Call Center

The database behind the Viewer will always reflect the most up to date version of Treatment Suite data, and is the same data being presented to all functions calling the Treatment Suite service.

The database behind the Builder will be used as a “staging area” to apply required maintenance to the Treatment Suite information and at any point in time may not reflect the data currently being accessed for production processes. Once proposed changes have been reviewed and approved by the Government and applied to the production version of the database, then Viewer data would be in synch with Builder data.

1.2.3 Treatment Suite Maintenance

As previously mentioned, Treatment Suite data from DOL’s legacy system will have been provided for initially loading the databases prior to implementation of the CBP. All subsequent maintenance to the data, using the Builder tool, will be performed by following a process defined by the Government, including their review and approval of all updates to be applied.

· Updates to Treatment Suite data are regularly initiated by the receipt of reference files indicating new ICD9/10s, CPTs, DRGs, GCNs, HCPCS, RCCs, Therapeutic Classes, etc. , from sources approved by the Government. There may also be a significant number of ad hoc updates generated by requests from District Offices, specific reviews, etc.

· The Contractor Health Advisors will work closely with the OWCP Medical Director to review and evaluate all reference files and existing Treatment Suite data. The OWCP Medical Director, based on any necessary changes, will present those changes to the OWCP programs (DFEC, DEEOIC and DCMWC), and will instruct the OWCP Treatment Suite Nurse to make the applicable changes. After review by the Government, and at their direction as to what data elements should be added/excluded, a Treatment Suites Nurse will enter updates using the Treatment Suites Builder tool.

· Maintenance to Treatment Suite data occurring in the Builder application will be applied by default to a separate "staging" version of the Treatment Suite database.

· The nurse will perform 100 percent QA (testing) to ensure the completeness and accuracy of Treatment Suite data updates.

· The updates entered in Treatment Suite Builder will be copied to the production database only after additional review, testing and approval by the Government, following a strict Change Management process.

· Re-verification will be performed to insure that the update of production correctly reflects the updates intended.

1.2.3.1 Reference Files

Using pre-set schedules or notifications from the Government, the Contractor will manage external updates as a routine part of CBP operations. The CBP Medical Bill Processing System (will provide code loaders expressly for updating information from external files, including CPT, ICD, DRG, NDC, and National Correct Coding Initiative Code Sets. The Contractor will also maintain the RCC reference files, which will provide coverage and non-coverage of RCC codes for a specific program.

Those reference file updates are also critical to the maintenance of Treatment Suites, specifically the diagnosis, procedure, therapeutic class, RCC, and DRG files. The Contractor will use the code loaders as the first step to update the Treatment Suite Builder database, presenting new codes to be analyzed for possible inclusion in Treatment Suites. Further, the analysis process will be automated with the creation of custom code loaders that match the file format of the incoming update files and compare them to the appropriate category of data already in the Treatment Suites. The loader process will run on a scheduled basis but can be invoked manually if file updates are received outside of the scheduled window.

The Treatment Suite Builder update process is as follows:

1. Contractor sends OWCP Medical Director file containing the ICD-9/10, procedure codes, etc. updates.

2. After consultation with programs, OWCP Medical Director sends back the file with the necessary parameters (Control code "D", age/gender limitations, etc.).

3. Updates are uploaded to the appropriate reference file (diagnosis, procedure, etc.) in the test environment and then tested.

4. If testing is successful, then the reference files in the Builder are updated.

1.2.4 Treatment Suites Functionality

Treatment Suites consists of a collection of data, grouped by diagnosis and type of service, which contains the information necessary to respond with processing rules that affect multiple aspects of CBP. In addition to the acceptable services that can be billed for a diagnosis, a treatment suite will also include legitimate complications of a diagnosis, which could direct the process to an alternative treatment suite. Each suite within the treatment suites contains a range of services and includes items such as:

· DRG codes

· CPT codes

· HCPCS codes

· Revenue codes

· Therapeutic class codes

· GCN codes

· Homegrown codes

· Basics, which are a set of services that are covered, regardless of the specific treatment suite (Although the basics are attached to all treatment suites, this suite functions from edit 863.)

The Contractor provides a consistent routine for determining whether billed services provided to claimants are appropriate for the claimant’s injury. Government policies are supported by treatment suites edits for bill processing in addition to supplying responses for Web Portal users and other functions within CBP.

1.2.4.1 Authorizations

One role of the Treatment Suites service is to identify and process prior authorization requirements. Each service code within a Treatment Suite is assigned a prior authorization level (1, 2, or 3). That level will be used in 2 distinct functions regarding authorizations:

· New Authorization Requests – the authorization level value will determine who may approve the request: 1= no prior authorization is required; 2 = the contractor’s Operations staff will review and approve the authorization, if possible; 3 = the authorization must be approved by the District Office.

· Bill Adjudication – the successful call to Treatment Suites will return the required authorization level for the billed service. Per the authorization level returned, the existence of any prior authorization required will be confirmed as part of further editing. A returned authorization level other than ‘1’ indicates that a pre-authorization is required. Edits will disposition appropriately when a service that requires an authorization does not have one recorded in the system.

1.2.4.2 CBP Bill Adjudication

The objective of Treatment Suites processing is to ensure that services billed for a claimant are appropriate for their billed diagnosis / accepted condition. All bill types will be subjected to some degree of Treatment Suite processing as part of the adjudication for both Medical and Pharmacy bill processing. Created as a Service to be called by both the pharmacy bill process and the medical bill process, he logic will be determined by the type of bill and / or certain eligibility scenarios. A specific set of Treatment Suite edits has been designed to record the success or failure of each line billed as returned from the service call. When a bill is submitted, the Treatment Suites edits must occur in the following order:

· 866 – The claimant’s eligibility record must contain at least one valid accepted condition.

· This edit will deny, when the case has been accepted (MC, PR DR, etc.), and the diagnosis in the eligibility file are not valid (Non specific, Not elsewhere classified, is equal to 999.99).

· When this occurs, although the bill has been systematically denied, a report should be generated that identifies all of the bills that were denied for this edit by District Office, so that the CE in the District Office can develop the case.

· 861 – The billed date of service must be within the date span of the accepted condition.

· This is actually an eligibility edit.

· If a bill is submitted with date of service that is prior to the start date of the accepted condition, the bill will be systematically denied for 861.

· 863 – The billed diagnosis code must match an accepted condition on eligibility (or a complication of an accepted condition).

· If the billed diagnosis is not a complication of the accepted condition, the bill should be denied.

· If the billed diagnosis is a complication of the accepted condition, and the procedure billed is listed the identified suite, the bill should pay.

· If the procedure is not listed in the suite although the billed diagnosis is a complication of the accepted condition, the bill/service should be denied.

· 865 – The service being billed must be within the Treatment Suite for the accepted condition (or complication).

· If the procedure code is not present in the accepted conditions suite, the bill is denied for edit 865.

· A report should be generated that identifies all of the bills that were denied for this edit by District Office, so that the CE in the District Office can develop the case.

· This is an edit that should also take the claimants billed diagnosis as referenced on the bill, and match with the claimants accepted condition to identify if the billed diagnosis is a complication of the claimants accepted condition. If there is a match on complication, then the billed procedure should be validated in the suite for the presence of. If present, pay the bill. If not present, deny the bill/service for 865.

As with all other edits, the Treatment Suite edit results will dictate proper disposition of the bill (i.e., approved for payment, denied or suspended).

1.2.4.3 Eligibility Inquiry

The implementation of the Treatment Suite service the Contractor will also provide real-time responses to inquiries from providers, claimants and staff (government and contractor). Available on the Portal or through IVR, the user will enter the claimant’s identification information along with the date of service and procedure code representing the service being requested. The inquiry will return an immediate response as to whether the service is approved and what level of authorization, if any, is required for the service.

1.2.5 Treatment Suite Logic

Noting that the logic of the Treatment Suite process will depend on the CBP function calling the service (bill adjudication, authorizations, and inquiries), the type of bill, and other exception scenarios described later in this document, the basic Treatment Suite logic is as follows:

· Treatment Suites is called for each bill/authorization request line

· The billed diagnosis code must match an accepted conditions (or a complication of an accepted condition) recorded on the claimant’s eligibility record

· The date of service must be within the date range of the matching accepted condition

· The Treatment Suite for that accepted condition must include the procedure code, RCC, DRG, Therapeutic Class, HCPCS, and CPT being verified

If there are multiple diagnosis codes presented on the bill or auth request, each diagnosis code will be evaluated as a possible match to an accepted condition until a match is found. If a claimant has multiple accepted conditions, each accepted condition (and its complications) will be evaluated until a match is found to the diagnosis or all accepted conditions have been exhausted.

The following sections describe the specific criteria appropriate for the type of bill or function calling the Treatment Suite process.

1.2.5.1 Authorizations

Authorization requests may include up to two ICD-9/10 Diagnosis codes; at least one is mandatory. Depending on the type of authorization request, the number of lines / procedure codes to be validated will vary. Except for claimant travel requests, authorizations follow the basic Treatment Suite logic flow described earlier (matching diagnosis to accepted condition, verifying date of service, confirming that the procedure code is in Treatment Suite). The authorization level returned will dictate the approval process for the authorization. Claimant Travel authorization requests will not include a diagnosis code and will always default to the Treatment Suite for 999.99.

1.2.5.2 Eligibility Inquiry

In addition to identifying the case number, the inquiry will include a date of service, and the procedure / revenue code being queried. The interface will also present the option to inquire into an NDC code to verify eligibility for Pharmacy services. It will follow the basic Treatment Suite logic flow described earlier without the match of a diagnosis code to an accepted condition (verifying date of service, confirming that the procedure/revenue/therapeutic class code is in Treatment Suite). It must also consider some specific eligibility scenarios (e.g., CA-16, SFC, etc.). The return from the Treatment Suite call will confirm that the service is valid for the claimant and will also indicate the required authorization level.

1.2.5.3 Bill Adjudication

While the Treatment Suite logic for bill adjudication is similar across bill types, there are specifics to be noted for each one, described in the sections below. Common to all is the first edit which verifies that the claimant’s eligibility has at least one valid accepted condition recorded. The second feature of the Treatment Suite editing is the looping process used to match the diagnosis code on the bill to an accepted condition on the claimant’s eligibility. When a match is found, the date of service is verified, and the Treatment Suite for that accepted condition is examined to verify the presence of the billed procedure code.

Prior to the execution of the “basic” Treatment Suite logic, specific eligibility scenarios and bill types will be evaluated in a Treatment Suite “pre-process”. The purpose of that function is to identify any alternative Treatment Suite logic path required, such as accessing a specific Treatment Suite, ignoring authorization levels, etc. All logic is described in the following sections.

1.2.5.3.1 Pre-Process to Identify Exception Conditions

The following exception conditions are identified and may require a separate logic path or force overrides of specific parameters following the basic logic flow:

CA-16 - if noted on eligibility and the date of service being billed is within the effective date range of the CA-16, the following Treatment Suite logic is applied. The purpose of the CA-16 table is to serve as a validation table of services covered under the CA-16 process, so as not to maintain a separate list of hard-coded values:

· A specific table built for CA-16 will be accessed to confirm whether or not the procedure billed is allowable for CA-16. That table will also include an indication of whether the procedure is limited to the 1st 15 days of the CA-16 period.

· If the procedure is allowed for CA-16 and billed per service date restrictions, no further Treatment Suite editing is required (authorizations are not validated)

· If the procedure is a CA-16 surgical procedure allowable only within the 1st 15 days, but billed on or beyond the 16th day OR if the procedure is not allowed under CA-16, the bill is not automatically denied; it will be processed as any non-CA-16 bill, through all appropriate editing

· This table must also recognize services that are covered for the entire period of the CA-16 period:

First 15 days Processing:

1. If a procedure is billed within the first 15 days of the CA-16, and the case is not accepted and is referenced in the listing of 15 day procedures, the procedure should be paid.

2. If a procedure is billed that is covered only for the first 15 days of the CA-16, and the case has not been accepted, but performed on the 16th day and procedure is a level 1 procedure, the service should be denied with edit 652.

3. If a procedure is billed that is covered only for the first 15 days of the CA-16, and the case has not been accepted, but is performed on the 16th day and the procedure is a level 2/3 procedure, normal editing will occur to check for authorization, if present (pay), if not present (deny for authorization edit and Treatment Suite edits where applicable).

4. If at any time the District Office has changed the case to another eligibility status (covered) has accepted the case, and this action has taken place during the CA-16 period, the system will cease the review of paying bills based on the CA-16 period.

Full CA-16 Period:

1. If a procedure is billed that is covered for the entire (full) period of the CA-16 Period and the case has not been accepted, the service should be paid.

2. If a procedure is billed that is covered for the entire (full) period of the CA-16 Period and the case has not been accepted, and the service is a level 1, 2, or 3, the service should be paid, bypassing all authorization and Treatment Suite editing, but not procedure file coverage editing.

3. If a procedure is billed that is covered for the entire (full) period of the CA-16 Period, and the case has been accepted, and this action has occurred by the District Office during the CA-16 period, and the service is a level 2, or 3, the system will begin normal processing, and deny/pay bills based on the situation (authorization, Treatment Suite editing etc;). Level-1 procedure will be paid, but validated through the procedure for file for procedural coverage.

4. If a procedure is billed and the case has not been accepted, and the procedure is not listed on the CA-16 covered listing (for the first 15 days or for the entire period), the system will deny the service for edit 655.

5. If a procedure is billed that is covered for the entire (full) period of the CA-16 Period, and the District Office has changed the eligibility case status to another covered/denied status, the system will cease the review of paying bills based on the CA-16.

6. If the procedure is billed outside of the CA-16 period, and the case has not been accepted, the service will be denied appropriately based on normal editing.

Prompt Pay bills– recognized as a specific bill type

· Homegrown procedure codes – a specific Treatment Suite built (PPA1 and PPA2) for Prompt Pay Homegrown codes will be accessed to confirm whether the procedure code is allowable (procedure validity will still be performed against the procedure file), to verify authorization levels required, and also to identify whether the procedure is subject to the interest calculation. Since the diagnostic procedure codes that can be submitted on the PPA bill or submitted as an attachment to the PPA bill will not be validated through the 999.98 suite, all of the diagnostic procedures that are referenced in the 999.98 suite will be applied to the PPA1 and PPA2 suites. This process will go under the assumption that if the diagnostic procedure is billed on the same bills as (SECOP, CNSLT etc.), the entire bill and services on the bill are subject to the interest rate calculation. If the diagnostic service is billed as an attachment, the bill is identified as a PPA2 and will not be subject to the interest rate calculation.

· Diagnostic procedures billed on a PPA1 bill or attached to a PPA1 bill will not validated in the 999.98 Treatment Suite. However, the Diagnostic Procedure billed on the PPA1 bill will be validated in the procedure file to determine specific coverage based on the identified control code or applicable end date, whichever applies during the period of verification:

· If the diagnostic procedure code is on the file with a control “D”, the bill will be placed in a work-queue, and the District Office will be notified through the work-flow tool that the diagnostic procedure billed contains a control “D”.

· If the diagnostic procedure code is covered (No control code D), but contains an end date for which the date of service billed is after the end date of the procedure, work-flow tool will inform the CE, who will be required to contact the Contracted Provider (SECOP, CNSLT, IMPAR etc.) to obtain the corrected information and provide direction through the work-flow tool on how to process the bill.

· If the control is equal to an “R” or “S”, the diagnostic service will be paid and no notification is needed to the District Office).

If any Treatment Suite edits are returned for Prompt Pay bills, the bill will be suspended and returned to the District Office for resolution and/or further instruction.

Short Form Closures - recognized by case status C1, C2, C4 & $1500 limit indicator

· Will access the Treatment Suite for the accepted condition 999.99 specifically

Diagnostic (not attached to Prompt Pay bill) – if the case is in UN/UD status, and the District Office has placed an accepted condition of 999.98 in the claimant eligibility file for a 30 day period:

· Will access Treatment Suite for the accepted condition 999.98 specifically, rather than matching a diagnosis to the accepted condition on eligibility

· Process will pay particular attention to the dates of services for the diagnostic procedure as authorized by the CE being within the date range of the 30 day date span of the 999.98 accepted condition on eligibility

· If the date of service is within the Date Span of the 999.98, the diagnostic procedure code will be validated in the Procedure file to identify the control code of the diagnostic procedure code and proceed as follows:

· If the diagnostic procedure code is on the file with a control “D”, the bill will be placed in a work-queue, and the District Office will be notified through the work-flow tool that the diagnostic procedure billed contains a control “D”.

· If the diagnostic procedure code on file is covered (No control code D), but contains an end date for which the date of service billed is after the end date of the procedure, the work-flow tool will inform the CE of this situation and provide instruction.

· If the control code is equal to an “R” or “S”, the diagnostic service will be paid and no notification is needed to the District Office.

1.2.5.3.2 HCFA-1500

· Treatment Suite editing is executed at the line level of the bill.

· Each bill line may have up to 4 Diagnosis codes indicated, utilizing the Diagnosis Code Pointers in block 24E, which refer to the ICD-9/10 diagnosis code in block 21.

· The looping process uses each diagnosis code, one at a time, to find a match with an accepted condition (or complication of an accepted condition). The matching process continues through all diagnosis codes and all accepted conditions until a match is found or all possible matches are exhausted.

· The billed date of service must be in the span of the matched accepted condition.

· The Treatment Suite of the matched accepted condition (or complication) is examined to confirm the inclusion of the billed procedure code.

1.2.5.3.3 Outpatient Bills

· For Outpatient bills submitted on a UB-04, Treatment Suite editing is evaluated at the header level of the bill concurrently with the procedure billed/cross-walked at the line level. The Principal Diagnosis on the Outpatient Bill will be used for validation and looping process through each of the accepted conditions on the claimants eligibility file. Validation of any other diagnosis on the Outpatient UB04 Bill is not required. The billed date of service must be in the span of the matched accepted condition

· Accessing the RCC-CPT crosswalk, it is used to determine whether the RCC requires a CPT code as the procedure code to validate in the Treatment Suite, and if so, verify that the CPT is cross-walked to the RCC code appropriately,

· Based on the RCC-CPT crosswalk , verify that the RCC or CPT is included in the Treatment Suite of the matched accepted condition (or complication)

· NOTE: Some additional logic changes will be identified to accommodate the decisions regarding the implementation of OPPS. For example, the RCC-CPT crosswalk will need to be retained for bills processed with date of service prior to implementation of OPPS logic; otherwise, the RCC-CPT crosswalk would be obviated with the implementation of OPPS.

1.2.5.3.4 Inpatient Bills

· Treatment Suite editing is not executed at the line level for Inpatient bills.

· Prior to entry into the Treatment Suite logic, a call to the 3M Grouper/Pricer is executed in order to derive the appropriate DRG code, which applies to the bill as a whole.

· The derived DRG code is the procedure that will be validated in Treatment Suites.

· The Diagnosis Code on the bill is ignored (no looping to match to accepted conditions).

· There is a looping match through the accepted conditions to find one that: 1) has a date span that includes the “statement from” date on the bill, and 2) the DRG code is in the Treatment Suite of the accepted condition.

· NOTE: For Inpatient bills, the complications of the accepted conditions are not a factor in the looping process.

1.2.5.3.5 Pharmacy POS Bills

The Treatment Suite Web service is called as a real-time function when Pharmacy POS transactions are entered. The same logic will apply to those Pharmacy bills entered into Pharmacy bill process from paper submissions.

· Treatment Suite editing is executed at the line level of the bill.

· There is no billed diagnosis code used for matching to accepted conditions on eligibility.

· The NDC code provided will be translated into a Therapeutic Class Code for verification in Treatment Suites

· There is a looping match through the accepted conditions to find one that: 1) has a date span that includes the date of service, and 2) the Therapeutic Class code is in the Treatment Suite of the accepted condition.

NOTE: For Pharmacy bills, the complications of the accepted conditions are not a factor in the looping process.

The Contractor will implement a process in which the NDC and quantity submitted on a physician-submitted drug bill (OWCP 1500) will be captured at data entry along with the accompanying ‘J’ code, (note that this process applies specifically to J8499 and J3490, but may include additional ‘J’ codes in the future). The physician-submitted bill will process through Treatment Suites following the 1500 path, checking billed diagnosis codes against the claimant's accepted condition, and ensuring the billed procedure (in this case the 'J' code) is covered. The 'J' code will be a covered service in Treatment Suites, but will have a Control Code to set to Review/Suspend, causing the bill to suspend.

As part of the bill resolution process, the NDC and quantity submitted will be used to manually obtain an AWP price in the Pharmacy system. Once obtained, the Pharmacy price will be manually applied to the professional bill. An Eligibility inquiry will also be performed to ensure the Therapeutic class for the billed NDC is covered for the claimant's accepted condition.

There is no fully automated way to process these bills, given the fact that the AWP price needs to be obtained and the Therapeutic class needs to be checked to ensure it is covered for the claimant's accepted condition. The Contractor will continue to evaluate this process to streamline it as necessary.

1.2.5.3.6 Authorization Level Exception

Claimant-billed travel is an area which may require an override of an authorization level returned from Treatment Suites. Typically, the authorization level for travel procedure codes are a level 1 (no authorization required) as long as the mileage is less than 200 miles and the amount billed is less than $75.00. However, for Claimant Travel submitted on a 957, as well as Provider Travel submitted on the OWCP-1500 billing form with the exception of ambulance services, if the sum of the expected / billed charges for travel procedure codes (A0100, A0110, A0120, A0130, A0140, A0170 ), exceeds $75 for a day, an authorization is required. Likewise, for A0080 & A0090, if the mileage exceeds 200 miles, an authorization is required (in both cases, the level 1 returned from Treatment Suites will be systematically over-written to level 3).

If a claimant travel bill is received, and it has recognized that a required authorization has not been entered (e.g., travel services billed by the claimant requires an authorization for services >=$75 or mileage >=200 miles), a request for the authorization will be communicated to the appropriate District Office by way of the Workflow Messaging service. Provider travel bills exceeding the $75 service or the 200 miles mileage criteria, on the other hand, will not be sent to the District but will be denied with the appropriate authorization edit.

1.3 Treatment Suites Business Process Flows – DFEC

The diagrams on the following pages depict the logic of the DFEC Treatment Suites process, as explained in the Business Process Description section of this document:

The Treatment Suite Pre-Processing Workflow illustrates the identification of any bill / eligibility scenario which may affect a bill’s continuing through the “basic” Treatment Suite workflows. This set of “decisions” is called by every other flow (per type of bill) to resolve any necessary logic branches or overrides.

The HCFA-1500 Treatment Suite Workflow depicts the logic specifically related to all other bill types, including looping through all Diagnosis codes and Accepted conditions in the matching process.

The Outpatient Treatment Suite Workflow depicts the logic specifically related to Outpatient Bills, including the use of the RCC/CPT crosswalk, and OPPS processes. The crosswalk should be used for history bills only.

The Inpatient Treatment Suite Workflow depicts the logic specifically related to Inpatient bills, including using 3M Grouper to derive the DRG, and also the exclusion of complications of accepted conditions in the matching process.

The Pharmacy Treatment Suite Workflow depicts the logic specifically related to Pharmacy bills entered into Pharmacy bill process (POS and manually entered), including the translation of NDC codes into Therapeutic Class codes.

The Authorization Request Treatment Suite Workflow depicts the logic related to processing new Authorization Requests.

1.3.1 Treatment Suite Pre-Processing Workflow

1.3.2 Prompt Pay Pre-Processing Workflow

1.3.3 CA-16 Pre-Processing Workflow

1.3.4 Short Form Closure Pre-Processing Workflow

1.3.5 999.98 Pre-Processing Workflow

1.3.6 HCFA-1500 Treatment Suite Workflow

1.3.7 Outpatient Treatment Suite Workflow

1.3.8 Inpatient Treatment Suite Workflow

1.3.9 Pharmacy Treatment Suite Workflow

1.3.10 Authorization Request Treatment Suite Workflow

2 Treatment Suites –DEEOIC

2.1 Treatment Suites Overview –DEEOIC

Treatment Suites processing is an automated procedure designed to ensure that billed services submitted to OWCP for payment are appropriate and authorized for the claimant’s accepted condition. Built to support Government medical policies and guidelines for each OWCP program (DFEC, DCMWC, DEEOIC), Treatment Suites consists of diagnosis codes linked to medical procedures, medications and other services typically included in the treatment for a diagnosed condition. Incoming bills are subjected to Treatment Suites edits implemented for each OWCP program, based on the accepted condition identified for a claimant and the services included in its Treatment Suite. Essentially, the existence of a billed service in the Treatment Suite of the accepted condition dictates whether a bill continues through payment processing or is denied.

Treatment Suites functionality plays a critical role in various areas of the CBP solution and is key to consistent, accurate decisions throughout the process:

· Both on-line and phone inquiry processes access Treatment Suites to verify that a claimant is eligible for a specific treatment

· Authorization requests are approved based on the authorization level recorded for each procedure / service in a Treatment Suite.

· Bills are validated against Treatment Suites for Pharmacy and Medical bills, both to ensure that the service billed is valid and to confirm that required pre-authorizations exist.

Treatment Suites is an existing feature of the current OWCP process, and its components will be fully supported with the implementation of the CBP solution:

· The Treatment Suite Builder tool will be used for maintenance to the data housed in Treatment Suites

· Updates to Treatment Suite data will be performed per government approved processes by medical personnel specifically identified with that responsibility

· The Viewer tool will be available for viewing and searching Treatment Suite data by all designated Government and Contractor personnel

· All applications accessing Treatment Suites as part of production processes will access the same set of data

2.2 Treatment Suites Business Process Description –DEEOIC

2.2.1 Service

A centralized Treatment Suite process is critical to providing consistency and accuracy in the CBP system, designed to eliminate billing errors and inappropriate payments of services.

The Treatment Suite editing will include all standard logic required to support Government approved processes. It will also account for any exception conditions which warrant special Treatment Suite logic outside of the normal flow. The key characteristic is that it will be uniform across all applications, with consistent responses and appropriate edit dispositions as necessary, based on the bill type.

2.2.2 Treatment Suite Tools

The Government-provided Treatment Suite Builder / Viewer tool is the primary instrument that will be used to implement, view, and maintain the Treatment Suites data. The Government has supplied the source code and database requirements to stand up the application. They have also provided current Treatment Suite data (i.e. ICD 9/10, CPT, HCPCS, TC, GCN and RCC) from their legacy system, which will be updated as needed to reflect all required modifications prior to go-live.

Both the Builder and Viewer applications will be accessible through the CBP Portal w/single sign-on. Access to the Builder will be controlled by strict security procedures. Only Treatment Suite Nurses and limited authorized personnel will be granted connection to the update functions that the Treatment Suite Builder provides. Access to the Viewer will be permitted for a much larger audience of designated Contractor and Government personnel in "view only" mode.

The Builder/Viewer tools are very similar in appearance, presented as a GUI interface to the user. The primary difference between the applications is that the Viewer is read-only and defaults to display the results of the selection entered, while the Builder allows the user to create a new Treatment Suite or group/subgroup or update/delete information in an existing Treatment Suite or group/subgroup.

2.2.2.1 Builder and Viewer Databases

The CBP system is required to maintain separate databases to support the Builder and Viewer tools. The architecture will be designed to allow maintenance functions to the Treatment Suite data in one environment, while at the same time ensuring that all areas of the production system are accessing identical up-to-date information in a another environment .

Treatment Suite data accessed at the production level will be consistent across all points of access:

· In the Treatment Suite Viewer, used for inquiries as needed

· Calls to Treatment Suite from medical bill process for Medical Bills and Authorizations

· Calls to Treatment Suites from pharmacy bill process for Pharmacy bills

· Calls to Treatment Suites for inquiries from IVR, Web Portal, & Call Center

The database behind the Viewer will always reflect the most up to date version of Treatment Suite data, and is the same data being presented to all functions calling the Treatment Suite service.

The database behind the Builder will be used as a “staging area” to apply required maintenance to the Treatment Suite information and at any point in time may not reflect the data currently being accessed for production processes. Once proposed changes have been reviewed and approved by the Government and applied to the production version of the database, then Viewer data would be in synch with Builder data.

2.2.3 Treatment Suite Maintenance

As previously mentioned, Treatment Suite data from DOL’s legacy system will have been provided for initially loading the databases prior to implementation of the CBP. All subsequent maintenance to the data, using the Builder tool, will be performed by following a process defined by the Government, including their review and approval of all updates to be applied.

· Updates to Treatment Suite data are regularly initiated by the receipt of reference files indicating new ICD9/10s, CPTs, DRGs, GCNs, HCPCS, RCCs, Therapeutic Classes, etc. , from sources approved by the Government. There may also be a significant number of ad hoc updates generated by requests from District Offices, specific reviews, etc.

· The Contractor’s Health Advisor will work closely with the OWCP Medical Director to review and evaluate all reference files and existing Treatment Suite data. The OWCP Medical Director, based on any necessary changes, will present those changes to the OWCP programs (DFEC, DEEOIC and DCMWC), and will instruct the OWCP Treatment Suite Nurse to make the applicable changes. After review by the Government, and at their direction as to what data elements should be added/excluded, a Treatment Suites Nurse will enter updates using the Treatment Suites Builder tool.

· Maintenance to Treatment Suite data occurring in the Builder application will be applied by default to a separate "staging" version of the Treatment Suite database.

· The nurse will perform 100 percent QA to ensure the completeness and accuracy of Treatment Suite data updates.

· The updates entered in Treatment Suite Builder will be copied to the production database only after additional review, testing and approval by the Government, following a strict Change Management process.

· Re-verification will be performed to insure that the update of production correctly reflects the updates intended.

2.2.3.1 Reference Files

Using pre-set schedules or notifications from the Government, Contractor will manage external updates as a routine part of CBP operations. The CBP Medical Bill Processing System will provide code loaders expressly for updating information from external files, including CPT, ICD, DRG, NDC, and National Correct Coding Initiative Code Sets. The Contractor will also maintain the RCC reference files, which will provide coverage and non-coverage of RCC codes for a specific program.

Those reference file updates are also critical to the maintenance of Treatment Suites, specifically the diagnosis, procedure, therapeutic class, RCC, and DRG files. The Contractor will use the code loaders as the first step to update the Treatment Suite Builder database, presenting new codes to be analyzed for possible inclusion in Treatment Suites. Further, the analysis process will be automated with the creation of custom code loaders that match the file format of the incoming update files and compare them to the appropriate category of data already in the Treatment Suites. The loader process will run on a scheduled basis but can be invoked manually if file updates are received outside of the scheduled window.

The Treatment Suite Builder update process is as follows:

1. Contractor sends OWCP Medical Director file containing the ICD-9/10, procedure codes, etc. updates.

2. After consultation with programs, OWCP Medical Director sends back the file with the necessary parameters (Control code "D", age/gender limitations, etc.).

3. Updates are uploaded to the appropriate reference file (diagnosis, procedure, etc.) in the test environment and then tested.

4. If testing is successful, then the reference files in the Builder are updated.

2.2.4 Treatment Suites Functionality

Treatment Suites consists of a collection of data, grouped by diagnosis and type of service, which contains the information necessary to respond with processing rules that affect multiple aspects of CBP. In addition to the acceptable services that can be billed for a diagnosis, a treatment suite will also include legitimate complications of a diagnosis, which could direct the process to an alternative treatment suite. Each suite within the treatment suites contains a range of services and includes items such as:

· DRG codes

· CPT codes

· HCPCS codes

· Revenue codes

· Therapeutic class codes

· GCN codes

· Homegrown codes

· Basics, which are a set of services that are covered, regardless of the specific treatment suite (Although the basics are attached to all treatment suites, this suite functions from edit 863.)

The Treatment Suites provides a consistent routine for determining whether billed services provided to claimants are appropriate for the claimant’s injury. Government policies are supported by treatment suites edits for bill processing in addition to supplying responses for Web Portal users and other functions within CBP.

2.2.4.1 Authorizations

One role of the Treatment Suites service is to identify and process prior authorization requirements. Each service code within a Treatment Suite is assigned a prior authorization level (1, 2, or 3). That level will be used in 2 distinct functions regarding authorizations:

· New Authorization Requests – the authorization level value will determine who may approve the request: 1= no prior authorization is required; 2 = the contractor’s Operations staff will review and approve the authorization, if possible; 3 = the authorization must be approved by the District Office.

· Bill Adjudication – the successful call to Treatment Suites will return the required authorization level for the billed service. Per the authorization level returned, the existence of any prior authorization required will be confirmed as part of further editing. A returned authorization level other than ‘1’ indicates that a pre-authorization is required. Edits will disposition appropriately when a service that requires an authorization does not have one recorded in the system.

2.2.4.2 CBP Bill Adjudication

The objective of Treatment Suites processing is to ensure that services billed for a claimant are appropriate for their billed diagnosis / accepted condition. All bill types will be subjected to some degree of Treatment Suite processing as part of the adjudication for both Medical and Pharmacy bill processing. Called by both pharmacy bill process and medical bill process, the logic will be determined by the type of bill and / or certain eligibility scenarios. A specific set of Treatment Suite edits has been designed to record the success or failure of each line billed as returned from the service call.