US20140372148A1

US20140372148A1 - System and method for providing mapping between different disease classification codes

Info

Publication number: US20140372148A1
Application number: US14/306,060
Authority: US
Inventors: Murlidhar Reddy
Original assignee: Syntel Inc
Current assignee: Atos Syntel Inc
Priority date: 2013-06-14
Filing date: 2014-06-16
Publication date: 2014-12-18
Also published as: US20140372976A1; US10607733B2; US9268907B2; US9898582B2; US20140372140A1; US10825565B2; US20140372142A1; US20140372978A1

Abstract

A system for translating healthcare codes from a first healthcare classification system to a second healthcare classification system may receive a first plurality of healthcare codes associated with the first healthcare classification system, receive a second plurality of healthcare codes associated with the second healthcare classification system, and map at least one of the first plurality to at least one of the second plurality according to user-defined parameters.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, U.S. Patent Application Ser. No. 61/834,908, filed Jun. 14, 2013, the disclosure of which is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

This disclosure relates generally to a computerized system and method for healthcare-related data, and more specifically to a system and method for providing mapping between different disease classification codes such as between ICD-9 and ICD-10 code sets.

BACKGROUND

Healthcare legislation specifies procedures for communicating information within the healthcare industry. For example, Title II (Administrative Simplification provisions) of the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”) required the Department of Health and Human Services to establish national standards for electronic health care transactions and national identifiers for providers, health plans, and employers.
On Jan. 1, 2012, an updated version of the healthcare transactions standard, HIPAA 5010, replaced version 4010A1, the current set of standards. Among various changes in this update, HIPAA 5010 mandates changes to the International Classification of Diseases (“ICD”), which is a nomenclature for the classification of diseases, injuries, and other medical conditions. More specifically, HIPAA 5010 requires healthcare payers and providers to transition from the current International Classification of Diseases, 9th Revision, Clinical Modification (“ICD-9”) to a 10th revision (“ICD-10”). This transition is referred to herein as the “ICD-10 migration” and, at present, all healthcare stakeholders (e.g., providers, payers, and employers), must make this transition by Oct. 1, 2015.
ICD-10 codes exhibit fundamental differences as compared with ICD-9 codes. For example, the form and information conveyed in ICD-10 codes is different than that of the ICD-9 codes. More specifically, ICD-9 codes contain three to five digits beginning with either a number or a letter, with a decimal point placed after the third digit, and the ICD-9 book indicates the level of specificity for each code. ICD-10 codes, on the other hand, are seven digits in length. The first three digits of the ICD-10 codes are similar to the ICD-9 codes, with a decimal point after the third digit. However, the digits that follow the decimal point have different, specific meanings. For medical and surgical procedures, for example, the digits that follow are specific to body part, surgical approach, and other qualifiers needed for billing. Similarly, the ICD-10 codes that represent diagnosis codes also have seven digits.
The first three digits of ICD-10 codes are similar to the ICD-9 code, but the additional digits add specificity to the code such as laterality, chronic versus acute, and so on. Another significant difference between the ICD-9 and ICD-10 code sets is the number of codes. More specifically, ICD-9 includes just over 14,000 diagnosis codes and almost 4,000 procedural codes. In contrast, ICD-10 contains over 68,000 diagnosis codes (clinical modification codes) and over 72,000 procedural codes. Due to such fundamental differences, mapping or translation from the ICD-9 code set to the ICD-10 code set presents challenges to ICD-10 migration. For example, while there are some one-to-one correspondences between ICD-9 and ICD-10 codes, there are also one-to-many, many-to-one and many-to-many correspondences and, in some cases, no correspondence at all. Accordingly, ICD-10 migration will undoubtedly affect many aspects of information collection, reporting requirements, billing and payment systems, potentially resulting in benefit, financial and clinical variations.

SUMMARY

The present invention may comprise one or more of the features recited in the attached claims, and/or one or more of the following features and combinations thereof. In one aspect, a computerized method for translating healthcare codes from a first healthcare classification system to a second healthcare classification system comprises receiving a first plurality of healthcare codes associated with the first healthcare classification system, receiving a second plurality of healthcare codes associated with the second healthcare classification system, and mapping at least one of the first plurality to at least one of the second plurality according to user-defined parameters.
In another aspect, a system comprises one or more computing devices including a memory having program code stored therein, and a processor in communication with the memory for carrying out instructions in accordance with the stored program code, wherein the program code, when executed by the processor, causes the processor to perform steps comprising receiving a first plurality of healthcare codes associated with the first healthcare classification system, receiving a second plurality of healthcare codes associated with the second healthcare classification system, and mapping at least one of the first plurality to at least one of the second plurality according to user-defined parameters.
In yet another aspect, a computer program product comprising non-transitory computer readable medium further comprising code for receiving a first plurality of healthcare codes associated with the first healthcare classification system, code for receiving a second plurality of healthcare codes associated with the second healthcare classification system, and code for mapping at least one of the first plurality to at least one of the second plurality according to user-defined parameters.

BRIEF DESCRIPTION OF THE DRAWINGS

This disclosure is illustrated by way of example and not by way of limitation in the accompanying FIGS. Where considered appropriate, reference labels have been repeated among the FIG.s to indicate corresponding or analogous elements.

FIG. 1 is a simplified block diagram of an embodiment of a computerized system that may be programmed with a set of instructions to perform any one or more of the functions, processes and methods discussed herein.

FIG. 2 is a simplified block diagram representation of a disease classification code mapping tool executed by the system illustrated in FIG. 1.

FIG. 3 is a simplified block diagram depicting an example architecture of the disease classification code mapping tool.

FIG. 4 is an example screen shot of a main page of the tool illustrating a process for selecting an application mode and business area in which to operate the disease classification code mapping tool illustrated in FIGS. 2 and 3.

FIG. 5 is an example of a screen shot illustrating selection of a specific application mode and a specific business area in which to operate the disease classification code mapping tool illustrated in FIGS. 2 and 3.

FIG. 6 is an example of a screen shot illustrating a process for configuring the disease classification code mapping tool for mapping of one particular disease classification code type to another particular disease classification code type.

FIG. 7 is an example of a screen shot illustrating a process for configuring the disease classification code mapping tool for mapping of yet another particular disease classification code type to further particular disease classification code type.

FIG. 8 is an example screen shot illustrating a process for uploading a particular disease classification code mapping file in a GEMs application mode of the disease classification code mapping tool.

FIG. 9 is an example screen shot illustrating a process for uploading a particular disease classification code mapping file in a specific application mode of the disease classification code mapping tool for use by a financial neutrality analysis tool.

FIG. 10 an EXCEL™ file to which the disease classification code mapping file is uploaded using the process illustrated in FIG. 9.

FIG. 11 is an example screen shot illustrating a process for extracting and appending disease classification codes not present in an uploaded disease classification code mapping file.

FIG. 12 is an example screen shot illustrating a graphic user interface for customizing a disease classification code mapping file by supplementing the code mapping file with extra disease classification codes received by the tool.

FIG. 13 is an example screen shot illustrating a disease classification code mapping customization process using the graphic user interface of FIG. 12.

FIG. 14 is an example screen shot further illustrating the disease classification code mapping customization process of FIG. 13.

FIG. 15 is an example screen shot further still illustrating the disease classification code mapping customization process of FIGS. 13 and 14.

FIG. 16 is an example screen shot illustrating a process for resetting the disease classification code customization process shown in FIGS. 13-15.

FIG. 17 is an example screen shot illustrating a graphic user interface for adding search tags to specified disease classification search codes.

FIG. 18 is an example screen shot illustrating a process for adding search tags to specified disease classification search codes using the graphic user interface illustrated in FIG. 17.

FIG. 19 is a screen shot illustrating a process for exporting disease classification code mappings from the tool.

FIG. 20 is a screen shot further illustrating the process of FIG. 19,

FIG. 21 is a screen shot further still illustrating the process of FIGS. 19 and 20.

FIG. 22 is an example of an exported disease classification code mapping using the process illustrated in FIGS. 19-21.

FIG. 23 is a screen shot illustrating a process for tagging disease classification codes with one or more skill sets.

FIG. 24 is a screen shot further illustrating the process of FIG. 23.

FIG. 25 is a screen shot illustrating a process for updating sill sets of medical coders and approvers.

FIG. 26 is a screen shot illustrating a process for creating tasks for specific users of the tool.

FIG. 27 is a screen shot illustrating a process for updating a disease classification code list internal to the tool with a received disease classification code list.

FIG. 28 is a screen shot further illustrating the process of FIG. 27.

FIG. 29 is a screen shot illustrating another process for updating a disease classification code list internal to the tool with a received disease classification code list.

FIG. 30 is a screen shot further illustrating the process of FIG. 29.

FIG. 31 is a screen shot illustrating a process for forward mapping ICD-9 codes to ICD-10 codes.

FIG. 32 is a screen shot further illustrating the process of FIG. 31.

FIG. 33 is a screen shot illustrating a look-up process for searching disease classification codes by code number.

FIG. 34 is a screen shot illustrating a look-up process for searching disease classification codes by description keyword.

FIG. 35 is a screen shot illustrating a graphic user interface for viewing disease classification code mapping confirmation histories.

FIG. 36 is a screen shot illustrating a process for confirming and rejecting selected disease classification code mappings.

FIG. 37 is a screen shot illustrating a process for inputting start and end dates of, and reasons for, confirmations of selected disease classification code mappings.

FIG. 38 is a screen shot illustrating an example email message automatically generated and sent to one or more users of the tool informing confirmation or rejection of selected disease classification code mappings.

FIG. 39 is a screen shot illustrating a process for backward mapping ICD-10 codes to ICD-9 codes.

FIG. 40 is a screen shot illustrating a process for identifying reimbursement equivalent ICD-9 codes of selected ICD-10 codes.

FIG. 41 is a screen shot illustrating a process for identifying similar forward and/or backward mappings of selected disease classification codes.

FIG. 42 is a screen shot illustrating a process for identifying business areas in which selected ICD-9 codes have been confirmed.

FIG. 43 is a screen shot illustrating a graphic user interface for viewing mappings of selected ICD-9 codes across all business areas in which they are confirmed.

FIG. 44 is a screen shot illustrating a process for bulk confirming selected one to one disease classification code mappings.

FIG. 45 is a screen shot illustrating a process for inputting start and end dates of, and reasons for, bulk confirmations of selected one to one disease classification code mappings.

FIG. 46 is a screen shot illustrating a process for identifying mapping percentages of selected categories of disease classification code mappings.

FIG. 47 is a screen shot of an example graphic user interface for viewing the ICD-9 to ICD-10 mappings of selected categories of disease classification codes produced by the process of FIG. 46.

FIG. 48 is screen shot illustrating a process for identifying mapping percentages of selected sections of disease classification code mappings.

FIG. 49 is a screen shot illustrating a report produced by the tool which tracks changes in disease classification code mappings across a selected date range.

FIG. 50 is a screen shot illustrating a graphic user interface for viewing mapping history details of individual disease classification codes identified by the report of FIG. 49.

FIG. 51 is a screen shot illustrating an example mapping distribution report produced by the tool which shows percentages of disease classification codes across a plurality of different disease classification code categories for a specified business area and a specified disease classification code type.

FIG. 52 is a screen shot illustrating an example mapping distribution report produced by the tool which shows percentages of disease classification codes across a plurality of different categories of confirmed disease classification codes for a specified business area and a specified disease classification code type.

FIG. 53 is a screen shot illustrating an example mapping distribution report produced by the tool which shows details of individual disease classification codes identified in the report of FIG. 51.

FIG. 54 is a screen shot illustrating an example report exported from the tool that includes details of individual disease classification codes in a sub-category of the disease classification code categories identified in the report of FIG. 51.

FIG. 55 is a screen shot illustrating a graphic user interface for generating a mapping report of specified, confirmed disease classification code mappings other than reimbursement mappings.

FIG. 56 is a screen shot illustrating a graphic user interface for generating a mapping report of specified, confirmed disease classification code mappings across different business areas.

FIG. 57 is a screen shot illustrating a report generated by the graphic user interface illustrated in FIG. 56.

FIG. 58 is a screen shot illustrating a graphic user interface for generating a mapping version report, along with an example such report, showing version change histories of disease classification code mappings for specified disease classification codes.

FIG. 59 is a screen shot illustrating a report generated by the tool which shows details of forward disease classification code mappings in a specified business area.

FIG. 60 is a screen shot illustrating a report generated by the tool which shows details of backward disease classification code mappings in a specified business area different than that shown in FIG. 59.

FIG. 61 is a screen shot illustrating a report generated by the tool which shows a comparison of disease classification code modifications made between different disease classification code revisions.

FIG. 62 is a screen shot illustrating graphic user interface for generating a mapping version report showing a selected category of disease classification code mapping modifications made between selected versions of disease classification code mappings.

FIG. 63 is a screen shot illustrating a mapping version report generated by the graphic user interface illustrated in FIG. 62.

FIG. 64 is a screen shot illustrating a graphic user interface for generating a report showing customized disease classification code mappings made during a specified time range.

FIG. 65 is a screen shot illustrating a report generated by the tool using the graphic user interface illustrated in FIG. 64.

FIG. 66 is a screen shot illustrating a report generated by the tool which shows all confirmed disease classification code mappings made during a specified time range for a specified business area.

FIG. 67 is a screen shot of a graphic user interface for generating a report, along with an example such report, showing an audit trail over a specified time period for disease classification code mapping requests made by third parties.

FIG. 68 is a screen shot illustrating an example report showing details of disease classification codes included in one such audit trail report generated by the graphic user interface of FIG. 67.

FIG. 69 is a screen shot illustrating a graphic user interface for generating a report, along with an example such report, showing a list of disease classification code mappings assigned to one or more responsible persons.

FIG. 70 is a screen shot illustrating a graphic user interface for generating a report showing disease classification code mappings that are expired or set to expire within a specified time range.

FIG. 71 is a screen shot illustrating a report generated by the graphic user interface of FIG. 70 showing details relating to disease classification code mappings that are set to expire in the current month.

FIG. 72 is a screen shot illustrating a graphic user interface for generating a report, along an example such report, showing an audit trail for work flow relating to mapping of a specified disease classification code.

FIG. 73 is a screen shot illustrating a graphic user interface for generating a report, along an example such report, showing an audit trail for work flow relating to mapping of disease classification codes within a specified date range.

FIG. 74 is a screen shot illustrating a graphic user interface that may be used to upload a specified claims data file by the tool for export to a payer entity.

FIG. 75 is a screen shot illustrating an example process for uploading a specified claims data file for export to a payer entity using the graphic user interface of FIG. 74.

FIG. 76 is a screen shot illustrating a graphic user interface that may be used to generate a report of historical data relating to a specified ICD-10 code in relation to a specified business area and/or a specified state, and which includes identification of one or more equivalent ICD-9 codes.

FIG. 77 is a screen shot illustrating an example report using the graphic user interface of FIG. 76.

FIG. 78 is a screen shot illustrating a claims mapping distribution report generated by the tool which shows percentages of disease classification code mappings across a plurality of different disease classification code categories for claims relating to one or more specified providers, one or more specified disease classification codes and/or one or more specified states.

FIG. 79 is a screen shot illustrating a claims amount distribution report generated by the tool which shows total charge and payment amounts for claims relating to one or more specified providers and/or one or more specified states.

FIG. 80 is a screen shot illustrating a claims conversion distribution report generated by the tool which shows the total number of disease classification code mappings across a plurality of different disease classification code categories for claims relating to one or more specified providers and/or one or more specified states.

FIG. 81 is a screen shot illustrating a claims code distribution report generated by the tool which identifies, and shows details of, disease classification codes for claims of a selecting mapping category that relate to one or more specified providers, one or more specified disease classification codes and/or one or more specified states.

FIG. 82 is a screen shot illustrating a provider comparison report generated by the tool which shows a comparison, by disease classification code, of claims percentages among various providers in one or more specified states and for a specified disease classification code mapping type.

FIG. 83 is a screen shot illustrating a provider comparison report generated by the tool which shows a comparison, by claims, of claims percentages among various providers in one or more specified states and for a specified disease classification code mapping type.

FIG. 84 is a screen shot illustrating a provider comparison report generated by the tool which shows a comparison, by claims paid and charged amount, of claims percentages among various providers in one or more specified states and for a specified disease classification code mapping type.

FIG. 85 is a screen shot illustrating a claims summary report generated by the tool which shows a summary of details relating to claims of all disease classification codes processed by the tool, in relation to claims processed by providers, by batch code translation.

FIG. 86 is a screen shot illustrating a claims audit trail summary report generated by the tool which shows details of claims requests made by payers with respect to forward or backward disease classification code mapping over a specified time period.

FIG. 87 is a screen shot illustrating a report generated by the tool which shows details about each of the number of claims of one of the claims requests illustrated in the audit trail summary report of FIG. 86.

FIG. 88 is a screen shot illustrating a report generated by the tool which shows details of the disease classification codes relating to one of the claims in the report of FIG. 87.

FIG. 89 is a screen shot illustrating a graphic user interface that may be used to upload a specified claims data file by the tool for export to a provider entity.

FIG. 90 is a screen shot illustrating an example process for uploading a specified claims data file for export to a provider entity using the graphic user interface of FIG. 74.

FIG. 91 is a screen shot illustrating a payer comparison report generated by the tool which shows a comparison, by disease classification code, of claims percentages among various payers in one or more specified states and for a specified disease classification code mapping type.

FIG. 92 is a screen shot illustrating a payer comparison report generated by the tool which shows a comparison, by claims, of claims percentages among various payers in one or more specified states and for a specified disease classification code mapping type.

FIG. 93 is a screen shot illustrating a payer comparison report generated by the tool which shows a comparison, by claims reimbursed and charged amount, of claims percentages among various payers in one or more specified states and for a specified disease classification code mapping type.

FIG. 94 is a screen shot illustrating a claims summary report generated by the tool which shows a summary of details relating to claims of all disease classification codes processed by the tool, in relation to claims processed by payers, by batch code translation.

FIG. 95 is a screen shot illustrating a claims audit trail summary report generated by the tool which shows details of claims requests made by providers with respect to forward or backward disease classification code mapping over a specified time period.

FIG. 96 is a screen shot illustrating a report generated by the tool which shows details about each of the number of claims of one of the claims requests illustrated in the audit trail summary report of FIG. 95.

FIG. 97 is a screen shot illustrating a report generated by the tool which shows details of the disease classification codes relating to one of the claims in the report of FIG. 96.

FIG. 98 is a screen shot illustrating a report generated by the tool which shows a distribution of disease classification codes for claims relating to one or more specified providers, in one or more specified states and/or for one or more specified disease classification code mapping types.

FIG. 99 is a screen shot illustrating a report generated by the tool in response to user selection of the “allocate” button in the report of FIG. 98, which shows a list of all disease classification codes contained in the report of FIG. 98.

FIG. 100 is a screen shot illustrating a graphic user interface that may be used to conduct a search within the tool for disease classification codes of a specified type by code description.

FIG. 101 is a screen shot illustrating a process for conducting a search within the tool, and example results produced thereby, for disease classification codes of a specified code type by code description.

FIG. 102 is a screen shot illustrating a process for conducting a forward search within the tool, and example results produced thereby, for all ICD-10 codes mapped to a specified ICD-9 code.

FIG. 103 is a screen shot illustrating a process for conducting a backward search within the tool, and example results produced thereby, for an IDC-9 code mapped to a specified ICD-10 code.

FIG. 104 is a screen shot of the main page of the tool illustrating selection of a specific application mode and business area in which to operate the disease classification code mapping tool.

FIG. 105 is a screen shot illustrating a process for creating various roles and levels of user access to the tool by an administrator.

FIG. 106 is a screen shot illustrating a process for editing information of existing users of the tool by an administrator.

FIG. 107 is a screen shot illustrating a process for adding additional approvers by an administrator to existing workflow.

FIG. 108 is a screen shot illustrating a process for allocating mapping tasks associated with a specified type of disease classification codes to approvers by an allocator.

FIG. 109 is a screen shot illustrating a process for prioritizing mapping by approvers of one or more selected disease classification codes.

FIG. 110 is a screen shot illustrating a process for allocating disease classification code mapping tasks by functional medical coder/approver group.

FIG. 111 is a screen shot illustrating a process for allocating disease classification code mapping tasks in one go by functional medical coder/approver group.

FIG. 112 is a screen shot illustrating a graphic user interface, generated by the tool in response to user selections made to in the process of FIG. 111, which may be used to allocate blocks of disease classification codes.

FIG. 113 is a screen shot illustrating an alternate embodiment of the disease classification code list included in the graphic user interface of FIG. 112.

FIG. 114 is a screen shot illustrating an additional code list, generated by the tool for display in or in addition to the graphic user interface of FIG. 112, showing a list of the allocated disease classification codes with functional group overlap.

FIG. 115 is a screen shot illustrating an example email message automatically generated and sent to one or more medical coders and/or approvers of the tool informing a task assignment.

FIG. 116 is a screen shot illustrating a process for transferring one or more disease classification code mapping tasks by an allocator to another medical coder or approver.

FIG. 117 is a screen shot illustrating a graphic user interface generated by the tool which may be used to unconfirm one or more selected disease classification codes prior to expiration.

FIG. 118 is a screen shot illustrating a process for generating a task allocation status report showing a status of tasks allocated to one or more medical coders and one or more approvers by a selected allocator in one or more specified business areas.

FIG. 119 is a screen shot illustrating a report generated by the tool showing the status of various tasks assigned to a selected one of the medical coders included in the task allocation status report of FIG. 118.

FIG. 120 is a screen shot illustrating a work list generated by the tool for a specified medical coder which shows a list of disease classification code mappings assigned to that medical coder.

FIG. 121 is a screen shot illustrating a pending list generated by the tool for the specified medical coder which shows a list of disease classification code mappings processed by the medical coder and awaiting approval.

FIG. 122 is a screen shot illustrating a rejected list generated by the tool for the specified medical coder which shows a list of disease classification code mappings processed by the medical coder and rejected by the approver.

FIG. 123 is a screen shot illustrating an escalated list generated by the tool for a specified approver which shows a list of disease classification code mappings which the approver can reassign to another medical coder.

FIG. 124 is a screen shot illustrating process for reassigning a disease classification code mapping listed in the escalated list of FIG. 123 to another medical coder.

FIG. 125 is a screen shot illustrating a rejected list generated by the tool for a specified approver which shows a list of disease classification code mappings which have been rejected.

FIG. 126 is a screen shot illustrating transfer of a disease classification code mapping, by the specified approver, from the rejected list of FIG. 125 to an approved disease classification code mapping list.

FIG. 127 is a screen shot illustrating a work list generated by the tool for a specified second level approver which shows a list of disease classification code mappings assigned to that second level approver.

FIG. 128 is a screen shot illustrating a pending list generated by the tool for the specified second level approver which shows a list of disease classification code mappings processed by the medical coder and awaiting approval or rejection by the second level approver.

FIG. 129 is a screen shot illustrating an approved list generated by the tool for the specified second level approver which shows a list of disease classification code mappings that are approved for a selected business area.

FIG. 130 is a screen shot illustrating a complete list generated by the tool for the specified second level approver which shows a list of disease classification code mappings that are approved as well as confirmed by all approvers for a selected business area.

FIG. 131 is a screen shot illustrating a pending list generated by the tool for a specified approver which shows an error message informing the approver that a mapping cannot be rejected more than three times.

FIG. 132 is a screen shot illustrating a graphic user interface generated by the tool which may be used to reallocate or confirm a disease classification code mapping already confirmed within the same department but with a different effective date.

FIG. 133 is a screen shot illustrating a process for reallocating or confirming a disease classification code mapping using the graphic user interface of FIG. 132.

FIG. 134 is a screen shot illustrating a graphic user interface generated by the tool which may be used to modify an end date a disease classification code mapping.

FIG. 135 is a screen shot illustrating a process for modifying an end date of a disease classification code mapping using the graphic user interface of FIG. 134.

FIG. 136 is a screen shot illustrating a graphic user interface generated by the tool which may be used to upload a document referenced during mapping of a disease diagnostic code.

FIG. 137 is a screen shot illustrating a graphic user interface of a work list in which is displayed for download a list of reference documents uploaded using the graphic user interface of FIG. 136.

FIG. 138 is a screen shot illustrating a graphic user interface which may be used to view ICD-10 codes previously backward mapped to specified ICD-9 codes.

FIG. 139 is a screen of the main page of the tool illustrating selection of yet another application mode and business area in which to operate the disease classification code mapping tool.

FIG. 140 is a screen shot illustrating a graphic user interface that may be used to create new mappings of specified ICD-9 codes to one or more corresponding ICD-10 codes.

FIG. 141 is a screen shot illustrating a graphic user interface that may be used to upload claims data for export to a payer or provider.

FIG. 142 is a screen shot illustrating an example uploaded file containing ICD-9 codes.

FIG. 143 is a screen shot illustrating a graphic user interface for uploading the ICD-9 code file illustrated in FIG. 142.

FIG. 144 is a screen shot illustrating an example uploaded file containing ICD-10 codes.

FIG. 145 is a screen shot illustrating a file, generated by the tool, containing ICD-10 code ranges corresponding to the ICD-10 codes contained in the file illustrated in FIG. 144.

FIG. 146 is a screen shot illustrating a graphic user interface for downloading the file containing ICD-10 ranges illustrated in FIG. 145.

FIG. 147 is a screen shot illustrating a graphic user interface that may be used by an allocator to search within the tool for disease classification codes for allocation based on a specified disease classification code range.

FIG. 148 is a screen shot illustrating a process for generating a read-only ICD-9 to ICD-10 code mapping.

FIG. 149 is a screen shot illustrating a process for generating a list of ICD-9 and ICD-10 codes and their descriptions based on a specified disease classification code description and a specified disease classification code type.

FIG. 150 is a screen shot illustrating an uploaded file containing financial neutrality average variance information for specified disease classification codes.

FIG. 151 is a screen shot illustrating a graphic user interface that may be used to upload the file illustrated in FIG. 150.

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific exemplary embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.
This application relates to the following applications all filed on even date herewith, the disclosures of which are incorporated herein by reference in their entirety; U.S. patent application Ser. No. ______, entitled System and Method for Ensuring Medical Benefit Claim Payment Neutrality Between Different Disease Classification Codes and having attorney docket No. 52809-124681, U.S. patent application Ser. No. ______, entitled System and Method for Automatically Modifying Source Code to Accommodate a Software Migration and having attorney docket No. 52809-124680, U.S. patent application Ser. No. ______, entitled System and Method for Analyzing an Impact of a Software Code Migration and having attorney docket No. 52809-124679, and U.S. patent application Ser. No. ______, entitled System and Method for Validating Medical Claim Data and having attorney docket No. 52809-124683.
References in the specification to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases may or may not necessarily refer to the same embodiment. Further, when a particular feature, structure, process, process step or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, process, process step or characteristic in connection with other embodiments whether or not explicitly described. Further still, it is contemplated that any single feature, structure, process, process step or characteristic disclosed herein may be combined with any one or more other disclosed feature, structure, process, process step or characteristic, whether or not explicitly described, and that no limitations on the types and/or number of such combinations should therefore be inferred.
Embodiments of this disclosure may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of this disclosure implemented in a computer system may include one or more bus-based interconnects between components and/or one or more point-to-point interconnects between components. Embodiments of this disclosure may also be implemented as instructions stored on one or more machine-readable media, which may be read and executed by one or more processors. A machine-readable medium may be embodied as any device or physical structure for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may be embodied as any one or combination of read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others.
Referring now to FIG. 1, an embodiment is shown of a system 100 for providing mapping between disease classification codes, i.e., between ICD-9 code set to ICD-10 code set. Although a migration from ICD-9 to ICD-10 is discussed herein for purposes of example, this disclosure is not intended to be limited to migration from ICD-9 to ICD-10, but encompasses migration from any one medical classification system to another medical classification system. The computing device 100 may be a personal computer, a tablet computer, a personal digital assistant (“FDA”), a media player, a cellular telephone, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken. The system 100 according to embodiments of the present disclosure may include a processor 202 (e.g., a central processing unit (“CPU”)), a memory 204, a video adapter 206 that drives a video display system 208 (e.g., a liquid crystal display (“LCD”), a cathode ray tube (“CRT”), a touch screen), an input device 210 (e.g., a keyboard, mouse, touch screen display, etc.) for the user to interact with the program (e.g., browser), a disk drive unit 212, a network interface adapter 214, an audio in/out jack 216 that allows audio to be outputted/received by an audio output device 218 (e.g., speaker, headphones) and microphone 220, respectively. Although a combined audio in/out jack 216 is shown for purposes of example, one skilled in the art should appreciate that separate devices may be provided for input and output of audio. It will be understood that that various embodiments of the computing device 100 may not always include all of these peripheral devices, and may instead include various subsets thereof. It will further be understood that the video display system 208 may, in some embodiments, be provided in the form of one or more conventional display monitors.
The disk drive unit 212 includes a computer-readable medium 216 on which may be stored a program code for a web browser with commonly installed plugin(s), such as Flash™ and/or Java™. In some cases, the browser may provide support for the emerging HTML5 WebRTC standard. Embodiments are also contemplated in which the browser could be on a mobile internet connected device, such as a phone or tablet, which has support for the emerging HTML5 WebRTC standard. In one embodiment, a custom application could be provided on an Internet connected mobile device. The term “computer-readable medium” shall be taken to include, but not be limited to, solid-state memories, optical media, flash memory, and magnetic media. Embodiments are contemplated in which the browser may run applications that are received from a server 224 over a network 102 via the network interface device 214 utilizing any one of a number of transfer protocols including but not limited to the hypertext transfer protocol (“HTTP”) and file transfer protocol (“FTP”). The network 102 may be any type of packet-switched data network including but not limited to fiber optic, wired, and/or wireless communication capability in any of a plurality of protocols, such as TCP/IP, Ethernet, WAP, IEEE 802.11, or any other protocol.
Compliance with the above discussed migration from ICD-9 to ICD-10 code sets may impact the software and systems of health care providers and payers. Embodiments of the present disclosure are directed to a disease classification code mapping tool which creates mappings or mapping files between ICD-9 and ICD-10 code sets in order to facilitate such migration.
The disease classification code mapping tool described herein illustratively includes one or more graphic user interfaces via which various disease classification code mapping personnel, e.g., medical coders, mapping approvers, task allocators and administrators, can access, configure and operate the tool. Illustratively, the tool may be operated to translate codes, i.e., create mappings between sets of disease classification codes, e.g., between one or more ICD-9 codes and one or more corresponding ICD-10 codes, in real time and/or in a batch process mode. The tool further illustratively includes a web interface via which payers, providers and/or other users may obtain disease classification code mappings.
The disease classification code mapping tool described herein illustratively supports ICD-9 and ICD-10 code sets, but is not limited to such code sets. In some embodiments, the tool performs forward mapping, i.e., mapping of ICD-9 codes to all corresponding ICD-10 codes. In other embodiments, the tool performs backward mapping, i.e., mapping of ICD-10 codes to all corresponding ICD-9 codes. In still other embodiments, the tool performs bi-directional mapping, i.e., forward mapping and backward mapping. Alternatively or additionally, the tool may perform reimbursement mapping, i.e., a single mapping of each ICD-10 code to a single ICD-9 code. Any such mapping may illustratively be performed on diagnosis codes (DC), procedure codes (PC) or both. Any such mappings may be exposed by the tool as a service that may be consumed by applications belonging to different platforms, and the tool illustratively supports workflow for publishing mappings.
The tool illustratively provides general equivalence mappings (GEMs) and supports loading newer versions of GEMs as well as mapping versioning. Additionally, the tool includes capability for customizing mappings by adding new mappings or confirming existing mappings. The tool may further provide guidance in selection of mappings using customer data. The tool is illustratively integrated with a rules engine for integrating complex business rules logic in mapping selection. The tool delivers consistency in the interpretation of mappings between different versions of disease classification code sets with centralized mapping and lookup availability.
The tool further illustratively provides searching capability for searching ICD-9 and/or ICD-10 codes by code description. Advanced searching capability may further include the ability to tag disease classification codes with meta-tags, thereby providing for intelligent searching of codes.
The tool further illustratively includes data analytics capability for creating reports relating to disease classification code categorizations, provider and/or payer comparisons, and the like. Trend analysis may further be performed on historical data, e.g., to narrow down one-to-many mappings.
Referring now to FIG. 2, a simplified block diagram is shown of a software environment of the system of FIG. 1. In the illustrated embodiment, the disease classification code mapping tool is implemented in the form of instructions stored in the memory 204 of the system 100 and executable by the processor 202 to perform the functions described herein. Alternatively or additionally, the instructions may be stored in whole or in part on the computer-readable medium 216, and/or on the server 224 and accessed by the processor 202 via the network 102. Alternatively or additionally still, the server 224 may include one or more processors which execute the instructions, and input/output data may be exchanged between the processor 202 and the server 224 via the network 102. In any case, the disease classification code mapping tool includes a user interface module 230, a data management module 240, a configuration module 250, an ICD code mapping module 260, a data analytics module 270, a business rules logic module 280, a reports module 290, a workflow management module 294 and a search engine 298.
The user interface module 230 illustratively includes a number of graphic user interfaces via which users of the tool may input information into the tool, access information from the tool, configure the tool for operation, operate the tool to create disease classification code mappings, manage workflow, create reports, and the like. In this regard, the user interface module 230 illustratively includes a plurality of graphic user interfaces 232 for inputting data, selecting configuration options and code searching, i.e., searching for disease classification codes. The user interface module further illustratively includes a plurality of graphic user interfaces 234 for viewing analytical reports and other information produced by and otherwise available via the tool. The user interface module 230 further illustratively includes a plurality of graphic user interfaces 236 for managing workflow of and to the tool.
The data management module 240 is operable to manage information input to the tool and information selection during operation of the tool. The data management module 240 is further operable to manage ICD code transfer within the tool, and to manage data downloads and uploads.
The configuration module 250 is operable to import and export ICD code mappings, to modify ICD code mappings, e.g., by adding ICD codes not present in ICD code sets, and to modify ICD codes, e.g., by adding code tags. The ICD code mapping module 260 is operable to create bidirectional mappings and reimbursement mappings between ICD-9 and ICD-10 code sets on both diagnosis codes and procedure codes, to customize ICD code set mappings and to create new ICD code mappings, e.g., for different business areas. The data analytics module 260 is operable to process and analyze claims data and produce analytical reports for payers and providers. The business rules logic 280 contains business rules for creating ICD code mappings and for generating various reports. The reports module 290 is operable to generate various mapping reports and produce reports generated by the data analytics module 260. The workflow management module 294 is operable to allow administrators, allocators, approvers and medical coders to create and manage work flow relating to the creation and confirmation of ICD code mappings. The search engine 298 is operable to search ICD codes by code description, and to conduct advanced searching using code tags.
Referring now to FIG. 3, a block diagram is shown depicting an example architecture 300 of the disease classification code mapping tool. The architecture includes, but is not limited to a presentation layer 302, a service interface layer 304, a business layer 306, and a data access layer 308. The presentation layer 302 illustratively provides a graphic user interface (“GUI”) for users 320 (e.g., medical coders, claims specialists, administrators, and the like) to upload data. The presentation layer 302 may be built, for example, with Microsoft Windows Forms using the .NET framework. The service interface layer 304 enables message transfer from the presentation layer 302 to the business layer 306 and vice versa, accepting inputs, and returning appropriate codes to the users. Supporting a Service Oriented Architecture (“SOA”), it also interfaces with other applications 330 external to the translation system such as, but not limited to, legacy systems and open systems.
The business layer 306 contains components which implement the business logic and rules (e.g., via a rules engine 340) responsible for the functionality of the tool. These components include, but are not limited to: an uploads processor, forward/backward mapping processor, customization/history processor, analytics processor, and a reimbursement processor.
The system supports SQL-based relational database systems through its data access layer 308, such as Oracle and Microsoft-SQL Server. Such a system database 310 acts as a central repository for all GEMs mappings, reimbursement mappings, mappings history, and customized mappings data. The system database 310 is coupled to a pre-defined mainframe interface 360 which provides for communication between the database 310 and the external applications 330.
The presentation layer 302 also handles any data access and business logic exceptions, and illustratively includes all graphic user interface related functionalities for web service deployment of the tool on, e.g., an internet information services (IIS) web application server 390.
An exception handling layer 370 handles all exceptions, and events are eventually logged into a file to provide a complete trace of an execution process. In some embodiments, a security layer 390 employs Windows authentication using Active Directory and role-based security.
The above described architecture is designed to support seamless vertical scaling. In the case of high transaction volume and/or requirements for catering to a large user base, the web/application servers can be clustered to deliver the load evenly across servers. Clustering of an IIS server with a load balance can serve to balance the load by distributing multiple instances of the application across separate processing machines. A suitable load-balancing algorithm, such as a round-robin algorithm may be employed for load balancing. Also, Microsoft Network Load Balancing (“NLB”) can be leveraged for load balancing capabilities. Efficient fail-over and fail back of the transactions and sessions during operation of an application can also be implemented. A fail-over mechanism for web/application servers can be implemented using a hot-stand-by node, which may help to alleviate crashes and service downtime. Accordingly, deployment in a cluster may ensure that there is no single point of failure for any application.
According to embodiments of the present disclosure, the term “user” herein may refer to any of the following entities, but not limited to the following entities: healthcare organization, allocator, approver, medical coder, administrator, super administrator. In light of embodiments of the disclosure discussed herein, one of ordinary skill in the art may understand the relationships between each of the above listed entities, which are used throughout. Further, according to embodiments of the present disclosure, systems and methods may restrict access to certain functionalities and processes to only certain types of users. For example, an administrator may be able to restrict the use of certain ICD codes by medical coders. As another example, an allocator may be able to allocate certain tasks or responsibilities associated with selected ICD codes to certain other types of users (e.g., medical coders). By way of non-limiting example only, a certain type of user (e.g., an administrator) may need to confirm a particular mapping before its actual implementation. Details of these user dynamics will be discussed in more detail below in conjunction with other embodiments of the present disclosure discussed below.
After a user enters a valid username and password at a login screen, the user is illustratively presented with a main page, an example of which is illustrated in the screen shot 4 of FIG. 4. The main page illustratively provides a number of options for operating the tool including, but not limited to: Home 402, Administration 404, Configure 406, Mapping 408, Reports 410, Payer Data Analyzer 412, Provider Data Analyzer 414, and Search 416. The user will generally first select an appropriate Application Mode and Business Area, e.g., using drop down lists 420 and 430, respectively. In some embodiments, the translator tool may operate in two different application modes 420: GEMs and Specific. In GEMs mode, all mapping and other results are generated based on GEMs files. As discussed above, GEMs are mapping tools that act mainly as a crosswalk between ICD-9 and ICD-10, such that one can look up an ICD-9 code and be provided with the most appropriate ICD-10 matches and vice versa. GEMs files are provided by the Centers for Medicare and Medicaid Services (“CMS”) and the Centers for Disease Control and Prevention. In Specific mode, on the other hand, all mapping and other results are generated based on code sets provided by an allocator. As used herein, an allocator refers to an entity associated with the user, such as an employee, or other authorized representative of a healthcare organization. The Business Area menu 430 provides a list of business areas, within which a user can view a mapping. Example business areas 430 may include, but are not limited to, Enrollments, Claims, ICD-10, Commercial, Care Administration, Clinical enrollments, Eligibility Management and Pre-authorization/Referral. As shown in the screen shot 5 of FIG. 5, the user has selected GEMs as the application mode 420 and Enrollments as the business area 430.
The following description of the disease classification code mapping tool will be presented, in order, according to the following topic areas:
I. Configuration
II. Mapping
III. Reports
IV. Data Analytics

- A. Payer Analytics
- B. Provider Analytics

V. Searching
VI. Workflow Management
VII. New Mappings
VIII. Code List Conversion and Financial Neutrality
I. Configuration
FIG. 6 shows an example screen shot 6 of a configuration home page. The configuration home page allows a user to upload ICD-9 codes, ICD-10 codes, as well as different versions of GEMs mapping files including those of years 2012, 2013, 2014, etc. Specifically, the user can upload versions of ICD code through code box 602 and mappings through mapping box 604. The translation system includes a configuration feature which may include the following functionality:

- Upload GEMs Mapping
- Upload Specific Mapping
- Upload Specific Mapping from GEMs Data
- Customize Mapping
- Add Code Tag
- Export Mappings
- Pre Allocation for Code (as per coder skill sets)
- ICD-10 Code Ranges
- Convert ICD-9 Code List/Ranges
- Upload GEMs Mapping—A user can upload full GEMs mappings, partial GEMs mappings, or simply view mappings of selected codes.

If a user chooses to upload a particular year's version of GEMs mapping (i.e., the 2013 GEMs mapping version), the user can select the desired version in drop down box 608. Upon clicking a browse button 610, the user may select a path from the dialog box from which to retrieve and upload the file or otherwise enter the file path in the file selection window 606. Use of upload button 612 may be disabled once a particular version GEMs file is uploaded. After a successful upload, an upload email is generated and sent to all registered users of the translation system.
The configuration feature also allows a user to perform a partial upload, or partial mappings (mappings of a portion of all codes) of a file. Specifically, the user can enter, or search for, a path of the file in the file selection window 606, click on the browse button 610, and click on the Partial Upload button 614. If the file size is too large to upload, then the file can be split into smaller parts and then uploaded using the partial upload feature. Also, this feature may be used for appending additional information. For example, ICD-9 code “707.20” does not have any equivalent ICD-10 code according to the GEMs mapping. In such situations, a user can define mappings for these codes as per their own organization's practice, and upload them using the partial upload functionality.
A user may view a selected code and associated description by clicking a view button 616. By selecting ICD-9 or ICD-10 codes and then clicking the view button 616, the user can view all codes with their description.
FIG. 7 is a screen shot 7 illustrating a process for uploading a specific mapping, which has the same upload and view functionality as the upload GEMs mapping feature discussed above, e.g., a code box 702, a mapping box 704, file selection window 706, browse button 708, upload button 710 and view button 712.
FIG. 8 is a screen shot 8 illustrating a process 802 for uploading code set files based on functional groupings for use by an external application such as, for example, the tool illustrated and described in co-pending U.S. patent application Ser. No. ______, entitled System and Method for Ensuring Medical Benefit Claim Payment Neutrality Between Different Disease Classification Codes and having attorney docket No. 52809-124681. The user selects a mapping file using the file selection window 804 and/or browse button 806, or selects the file by entering a file description in a dialog box 808, and then selects the submit button 810. The uploaded file will illustratively be an Excel™ file or other .xls file.
FIG. 9 is a screen shot 9 illustrating a process 902 for uploading a specific mapping from the GEMs data in the form of a text file or Excel™ spreadsheet with a code list (or range). The user may specify an Excel™ or text file that contains the subject ICD-9 code list and code ranges. A screen shot 10 showing an example Excel™ file of a code list and range is shown in FIG. 10. The user selects a code set type, e.g., ICD-9 diagnosis codes 904 or ICD-9 procedure codes 906, then selects a GEMs file using the file selection window 908 and/or browse button 910, or selects the file by entering a file description in a dialog box 912, and then selects the upload button 914. The tool will then convert the code list and ranges into an appropriate format. The system can identify every ICD-9 code within the selected code range as from the ICD-9 codes listed in the GEMs mappings and populate those codes in the specific mode master tables. Likewise, the mapped ICD-10 codes within that range, along with their descriptions, will also be populated. For Backward Mapping, the user would need to specify an Excel™ or text file which contains the ICD-10 code list and code ranges, and the a mapped list of ICD-9 codes will populated in a similar fashion.
FIG. 11 is a screen shot 11 illustrating a process 1102 for extracting and appending ICD-9 codes not present in a customer uploaded input file. The user selects a code set type, e.g., ICD-9 diagnosis codes 1104 or ICD-9 procedure codes 1106, then selects an input file using the file selection window 1108 and/or browse button 1110, and then selects the upload button 1112. The tool will accept customer-provided ICD codes and code lists from the front end, and it will identify extra ICD-9 codes referencing the GEMs mapping codes. The extra codes may be tagged to a defined functional group within the tool. The tool also has the ability to extract the ICD-9 codes. In any case, the user may select the export button 1114 to export the file.
FIG. 12 is a screen shot 12 illustrating a process 1202 for customizing an existing ICD code mapping. To customize a forward mapping 1204 (ICD-9 to ICD-10), a user enters an ICD-9 code to be mapped in box 1208, and/or uses a code lookup button 1210 to identify a desired ICD-9 code. The get equivalent ICD-10 code button 1212 is then selected, and a list of all candidate mapped ICD-10 codes is provided as illustrated by the user interface 1302 shown in the screen shot 13 of FIG. 13. Illustratively, the user interface is configured, e.g., by color coding or other distinguishing feature(s), to identify and distinguish the candidate ICD-10 codes as between GEMs mapping 1308 and customized mapping 1310. The provided ICD-10 code(s) can be saved as a mapped code(s) by selecting the save button 1302.
Editing of a candidate code may be accomplished by selecting the edit link 1306 adjacent to the ICD-10 code line. An example of such an editing process is illustrated in the screen shot 14 of FIG. 14 which illustrates a backward mapping of a selected ICD-10 code to one or more equivalent ICD-9 codes using the user interface 1202 illustrated in FIG. 12. As shown in the user interface 1410, the selected ICD-10 code is identified by the tool as having three sets of corresponding ICD-9 codes. In the example illustrated in FIG. 14, the first line of equivalent ICD-9 codes is selected for edit, by selecting the edit link adjacent to the first line of equivalent ICD-9 codes in the user interface 1410, which action produces the user interface 1402 above the user interface 1410. The user interface 1402 shows each of the equivalent ICD-9 codes in a separate window, e.g., 1404, and the one or more equivalent ICD-9 codes in the user interface 1402 may be updated, i.e., by adding one or more additional ICD-9 codes, by changing one or more of the ICD-9 codes and/or removing one or more of the ICD-9 codes shown. Selection of the update button 1406 produces the updated list in the user interface 1410, and changes can be saved using the save button 1312. New rows of ICD codes can also be added in either forward or backward mapping by selecting the add new row button 1504 as shown in the user interface 1502 of the screen shot 15 shown in FIG. 15. As shown in the screen shot 16 of FIG. 16, customized ICD codes can be reset to their original GEMs mapping in some embodiments by selecting a reset button 1604 which may be provided in user interface 1602 of mapped code candidates.
FIGS. 17 and 18 are screen shots 17 and 18 respectively illustrating a process 1702 for adding a code tag to one or more ICD codes. This feature allows a user to add a tag to selected ICD codes to facilitate a search for ICD-codes. Therefore, at any later point in time, the user can search for a code by the associated tag. The user can search for a desired ICD code by entering the code, or a portion thereof, in search field of the user interface 1702. By selecting get description in the user interface 1702, the user is presented with another user interface 1802 showing a list of codes matching the search terms. The user can add a tag to any of the listed codes by clicking an edit link adjacent to the code in the interface 1802. As shown in FIGS. 17 and 18, the user is using the feature to add a search tag for ICD codes starting with “017”.
FIGS. 19-22 are screen shots 19-22 respectively illustrating a process 1902 for exporting mappings. The tool can illustratively export mappings in flat file format, although it is contemplated that the tool may alternatively or additionally export the mappings in any suitable format. For export, the user has the ability to download any original mapping or customized mapping. As shown in FIG. 19, the user interface 1902 includes all mapping 1904 and functional group wise mapping 1906 buttons for exporting correspondingly selected mappings. By selecting all mapping 1904, all original mappings (GEMs or Specific, depending upon operating mode) can be exported. The mapping is selected in a dialog box 1908, and a download button 1910 is selected to download the specified mapping file (e.g., a forward or backward mapping file). As shown in FIG. 20, by selecting functional group wise mapping 1906, the tool modifies the user interface 1902 to include a functional group selection dialog box 2002 which may be used to select a desired functional group or business area of mappings, i.e., a collection of ICD code mappings previously tagged with an identification tag identifying those ICD codes in the collection with the corresponding business area. When the functional group is selected, the download button 1910 is then selected to download the specified mapping file. As shown in FIG. 21, a file download dialog box 2102 will open in either case (all mapping or functional group wise mapping) after clicking the download button 1910. The user can save the mapping to any location in flat file format (.txt) or any other format, for that matter. The downloaded file name may be in the mapping type .txt format. For example, “forward_mapping (ICD-9-CM_to_ICD-10_CM_Mapping).txt as shown in FIG. 21. A screen shot 22 illustrating an example of a downloaded file 2202 is shown in FIG. 22.
FIGS. 23-25 are screen shots 23-25 respectively illustrating a process for tagging ICD codes with different skill sets, e.g., as between different parts of the body. In one embodiment, the illustrated process is restricted for use by authorized administrators or allocators, which can enter an ICD code in the text box of a user interface identical (or similar) to the user interface 1702 illustrated in FIG. 17 to retrieve its description as shown in the user interface 2302 in FIG. 23. By clicking on the edit link in the user interface 2302, the tool produces a menu 2402 above the interface 2302 of all available skill sets (e.g., body parts) associated with the selected ICD code, as shown in FIG. 24. The tool adds a tag to the selected ICD code for each skill set selected from the menu 2402 of skill sets.
In addition to adding skill sets to ICD codes, the tool provides for updating skill sets available for certain medical coders and approvers. As shown in FIG. 25, a selectable list 2502 is shown of business codes, i.e., users of the system, e.g., allocator, approver, medical coder and business user, of business areas, e.g., enrollments, care administration, claims, commercial, eligibility management and pre-authorization/referral, and of skill sets, e.g., hand, heart, leg, eye, ear nose, lungs, fever and skin. Certain medical coders and/or approvers may be proficient (or certified) to code diagnosis and procedures related to certain body parts (i.e., skill sets) and not others. Therefore, medical coders and their approvers may only be allowed to code certain diagnosis and procedures. This functionality provides authorized users with the ability to modify the codes of associated skill sets that a medical coder and approver are allowed to use.
FIG. 26 is a screen shot 26 illustrating a process for allowing authorized users to create tasks for a specific medical coder, approver, and the like. Specifically, from the user interface 2602 shown in FIG. 26, an authorized user (e.g., allocator) may select a medical coder 2604 and approver 2606, and a list of codes 2612 will be displayed. By selecting “all codes” 2608, the list of codes 1612 will include all codes assigned to the selected combination of medical coder and approver. Alternatively, the search button 2610 may be used to search for and select such codes. The illustrated process may be selectively carried out with respect to forward and backward mapping via appropriate selection in the user interface 2602. In any case, by checking a corresponding box, e.g., 2616, the adjacent code can be added (or removed by unchecking) from the capability of the above selected medical coder. Comments relating to the task allocations can be made and attached to the allocation using the comment field 2614.
FIGS. 27-28 are screen shots 27-28 respectively illustrating a process for allowing a user to work with ICD codes within selected ranges. With the user interface 2702, the user can specify input an excel file via a dialog box 2708 which contains a list of ICD-10 codes (e.g., diagnosis 2704 or procedure 2706 codes). By selecting the get ICD-10 code ranges button 2710, the tool will retrieve GEMs mapping data from its database in a sorted order, and compare this sorted list to the range of codes in the list input by the user. The tool will output, in the form of an Excel™ spreadsheet, a list of ICD-10 codes from the GEMs data that correspond to the range of ICD-10 codes input by the user, as shown by the pop-up box 2802 illustrated in FIG. 28. The user may view and/or save this file as appropriate.
FIGS. 29-30 are screen shots 29-30 respectively illustrating another process for uploading ICD code ranges for which the input is a range of ICD-9 codes instead of ICD-10 codes. For example, the user can upload via a user interface 2902, e.g., with file description 2904, an excel file containing a list of ICD-9 codes (diagnosis or procedure), and the tool will retrieve GEMs data from its database in a sorted order and compare this sorted list to the range of codes in the list uploaded by the user. In addition to an output list of ICD-9 codes in accordance with the GEMs data, the tool may output a list of mapped ICD-10 codes (from the GEMs data) that correspond to the range of ICD-9 codes, which file may be downloaded using the link 3002 as shown in FIG. 30.
II. Mapping
Upon clicking on the mapping tab 408 (FIGS. 4-5), functionalities are presented to the user including GEMs mapping (e.g., diagnosis and procedure mapping) and section mapping. If the user selects GEMs mapping, the user is presented with four functionality options: Forward Mapping, Backward Mapping, Reimbursement Mapping, and Highlighting Similar Mapping/Color Coding.
FIG. 31 is a screen shot 31 illustrating a process for forward GEMs mapping of selected ICD-9 codes. A user interface 3102 includes a set of radio buttons 3104, 3106 and 3108 for selecting forward, backward and reimbursement mapping respectively, and in the screen shot 31 of FIG. 31 the forward mapping radio button 3104 is selected. In response to selection of the forward mapping button 3104, the tool causes the user interface to display a dialog box 3110 for entering a selected ICD-9 code to forward map to one or more ICD-10 codes. A code lookup button 3116 is included to assist locating ICD-9 codes. When the ICD-9 code is selected, a graphic 3120 is displayed by the tool which shows the selected ICD-9 code and its description. Upon user selection of the get equivalent ICD-10 code button 3112, the tool searches the database and presents via a user interface 3130 listing corresponding ICD-10 codes. As shown in the example screen shot illustrated in FIG. 31, the user interface 3130 includes an option column 3132 by which a user can select a specific ICD-10 code, having a description shown in a description column 3134, to which to map the entered ICD-9 code by checking a box adjacent to the particular ICD-10 code in the option column 3132. A status column 3136 of the user interface 3130 displays a mapping status of the corresponding ICD-10 code in relation to the selected ICD-9 code. As shown in FIG. 32, when the user has selected the check box in the options column 3132 for the firsts ICD-10 code listed, and has then selected the save button, and the tool displays a message 3202 indicating that the selected mapping has been saved.
Illustratively, the forward mapping feature illustrated in FIGS. 31-32 provides three particular utilities: Code Look-up, View Mapping History, and Confirm Mapping. FIG. 33 is a screen shot 33 illustrating the code look-up process which allows a user to view ICD-9 codes by entering an ICD-9 code into an ICD-9 code field 3302 and then selecting a search button 3306. As shown in FIG. 33, the tool conducts the search and produces a graphic 3310 which shows the code and its corresponding description, as well as any tag(s) associated therewith. As shown in the screen shot 34 of FIG. 34, users may alternatively or additionally view ICD-9 codes by entering a keyword description of an ICD-9 code, which produces a list 3402 of all ICD-9 codes that match the entered description. Using the look up by code methodology, a user can also enter an approximate, or a portion of an ICD code (e.g., “416”), or a portion of a code description. Upon clicking the search button 3306, all ICD-9 codes starting with 416 will be displayed. Alternatively still, the user may select one or more number and/or letter links 3308 to search for codes starting with the selected number(s) and/or having descriptions starting with the selected letter(s). Illustratively, all ICD-9 code records may be produced in the list 3402 by entering “%” in the code box 3302. In any case, a user can select any displayed ICD-9 code for mapping services.
FIG. 35 is a screen shot 35 illustrating a user interface 3502 produced by the tool which allows a user to view details of any previously made mappings. Specifically, as shown in the illustrated example, a user can view who made previous mappings and when the mappings were originally made, and when they were confirmed or unconfirmed. Other history details include the approver name, reason by approver, effective date, and end date.
FIG. 36 is a screen shot 36 illustrating a process for confirming forward mappings. As discussed above, multiple mappings may be available for a particular ICD code. For these codes, a user may need to confirm one or more, of the multiple mappings available. Any code can be confirmed by simply checking or unchecking the option button in the option column of the code list 3130, e.g., box 3602 as shown in FIG. 36, and clicking on save (see FIG. 31). To unconfirm any code mapping, a user can simply uncheck the option button and then select save. Successful changes are notified via a suitable on-screen message 3604.
A user can also specify a certain period for which a code mapping confirmation is valid. Specifically, an authorized user (e.g., administrator) can go to the mapping section and click on GEMs mapping and then to diagnosis. The authorized user may then enter an ICD-9 code inside a textbox and get an equivalent ICD-10 code, as was previously discussed. After checking the box and saving, as shown in the example screenshot 37 in FIG. 37, a pop-up window 3702 will open, prompting the authorized user to enter an effective date 3706 and end date 3704 for the confirmation, and a reason in a text box 3708 for setting the time restrictions. These dates define the period of time for which a user would like to confirm a selected code mapping. A corresponding reference document can be uploaded by selecting the button 3710.
After confirming a mapping, an email is automatically generated and sent by the tool to the administrator as well as all medical coders/approvers describing the newly confirmed mapping. This email is sent in situations when the administrator or allocator is confirming any mapping. If the user is an approver, and the approver approves any code, mail is sent from the administrator to the medical coder for the given confirmation. Similarly, an email is sent when a mapping is rejected, a copy of which is sent to the administrator and his allocator. FIG. 38 is an example screen shot 38 of such an email 3802 illustrating the above discussed confirmation and including a chart 3804 including relevant ICD code information.
FIG. 39 is a screen shot 39 illustrating a GEMs backward Mapping process. As shown in the illustrated example, backward mapping provides equivalent ICD-9 codes for a specified ICD-10 code. For example, the backward mapping button 3106 is selected in the user interface 3102, the tool modifies the interface 3102 to include an ICD-10 dialog box for entering a selected ICD-10 code. When an ICD-10 code is entered, the tool produces a graphic 3902 of the selected ICD-10 code and its description, and upon clicking the “Get Equivalent ICD-9-CM Code” box in the user interface 3102, the tool displays a list 3904 of corresponding ICD-9 codes. Similar to the forward mapping feature, the backward mapping feature allows a user to perform code look up and mapping confirmation functionality, and the list 3904 likewise illustratively includes an option column 3906, an ICD-10 code description column 3908 and an ICD-10 code status column 3910.
As shown in the example screenshot 40 of FIG. 40, the translation tool can also perform reimbursement mappings by selecting the reimbursement mapping button 3108 in the user interface 3102. As used herein, reimbursement mappings are mappings that were created to provide a temporary but reliable mechanism for mapping records containing ICD-10 diagnosis and procedure codes to “reimbursement equivalent” ICD-9 diagnosis and procedure codes, so that while systems are being converted to process ICD-10 claims directly, the claims may be processed by the legacy systems.
Unlike GEMs mappings, which include all plausible translation alternatives for each code in a system, the reimbursement mappings offer a single recommended mapping of each ICD-10 code to a single ICD-9 code alternative. Specifically, each ICD-10 diagnosis code is mapped to a single ICD-9 diagnosis code and each ICD-10 procedure code is mapped to a single ICD-9 procedure code. For example, if a user enters a desired ICD-10 code in the ICD-10 code field and then selects the “Get equivalent Reimbursement CM code” button, the tool produces a graphic 4002 identifying the selected ICD-10 code and its text description, and a user interface 4004 containing a single mapped ICC-9 reimbursement code.
FIG. 41 is a screen shot 41 illustrating a code map highlighting feature. As shown in FIG. 41, the backward code mapping of FIG. 39 is shown in which the two rows of ICD-9 codes in the user interface 3904 are specifically configured to identify a mapping category. In one embodiment, different colors (or, alternatively four different cross-hatchings or other line-based shading) are used to identify different mapping categories, and in the illustrated embodiment four different colors are used to identify four different corresponding mapping categories. For example, blue (or other color shading) may be used to identify codes showing reimbursement mapping, orange (or other color shading) may be used to identify codes showing similar reimbursement mapping and backward mapping, yellow (or other color shading) may be used to identify codes showing similar mapping in forward and backward mapping, and gray (or other color shading) may be used to identify codes showing different mapping in forward and backward mapping. In FIG. 41, for example, the first row in the user interface 3904 is yellow, identifying the corresponding ICD-9 code as showing similar mapping in forward and backward mapping, and the second row is orange, identifying the corresponding ICD-9 code as showing similar reimbursement mapping and backward mapping. Illustratively, the tool may include a suitable chart 4106 with the user interface 3904 which defines the illustrated highlighting.
FIGS. 42 and 43 are screen shots 42 and 43 respectively illustrating a process for allowing an administrator to check any confirmed code mappings in a selected business area. Specifically, an administrator can log in, select a business area and check in a selected business area or all lines of business (“LOB”), what particular codes have already been confirmed. As shown in FIG. 42, for example, an administrator has accessed the forward mapping illustrating in FIG. 31, and in this mapping the tool includes an “all LOBs” link 4202 which, if selected, produces the report 4302 illustrated in FIG. 43 listing all business areas with which the ICD-9 code listed in the user interface 3130 is already confirmed.
Accessible by the administrator and the allocator type users, another feature of the system allows administrators and allocators the ability to confirm a group of one-to-one type mappings at one time, otherwise known as a “bulk confirm”. As shown in the example screen shot 44 in FIG. 44, the user is able to view a detailed list of potential mappings between selected ICD-9 and ICD-10 codes. A user interface 4402 is illustratively produced by the tool which includes a forward mapping button 4404, a backward mapping button 4406, a priority menu 4408, a search type menu 4410, a description dialog box 4412, a “get all codes” selection box 4414 and a search button 4416. By checking multiple checkboxes at one time, the multiple code mappings shown in the corresponding table 4420 produced by the tool will be confirmed by one click of the confirm button 4422. Once the user selects the confirm button 4422, a pop up window 3702 may open, as illustrated in the screen shot 45 of FIG. 45, prompting the user to enter a reason for the confirmation, as well as start and end dates for when the confirmation is effective.
The disease classification code mapping tool further allows a user to work on code mappings with respect to a particular section or category of code. FIG. 46 is a screen shot 46 illustrating a process by which a user can enter a category for a code (e.g., all ICD-9 codes beginning with 290), and the system will retrieve and display any possible mapped ICD-10 code categories as well as the percent distribution of codes from these codes. A user interface 4602 associated with this process includes a category button 4604, a section button 4606, an ICD-9 code input box 4608 and a search button 4610.
The functionality works in a similar fashion for backward mapping described above, except the input is an ICD-9 category 4604 or ICD-9 section 4606, and a corresponding ICD-9 code, and the output includes a forward mapping list 4620 and a reverse mapping list 4630. In the illustrated example, the ICD-9 category button 4604 is selected, and the forward mapping list 4620 shows all ICD-10 code category ranges in the category in which the selected ICD-9 category range is forward mapped, along with the percentage of mapping, and the backward mapping list 4630 shows all ICD-9 code category ranges backward mapped to the ICD-10 code categories listed in the forward mapping list 4620, along with the percentage of mapping. The screen shot 47 of FIG. 47 shows an example detailed list 4702 of the ICD-9 and corresponding ICD-10 codes in the forward mapping list of the ICD-9 code category range selected in the example shown in FIG. 46. The list 4702 is illustratively produced by the tool upon selection of the ICD-9 code category range within the forward mapping list 4620.
The screen shot 48 of FIG. 48 shows an example of section mapping using the process illustrated in FIG. 46. In the illustrated example, the user has selected the section button 4606 in the user interface 4602 and has entered a range of ICD-9 diagnosis codes. The forward mapping list 4802 includes a list of all ICD-10 code sections forward mapped to the identified ICD-9 code range, along with corresponding mapping percentages, and the backward mapping list 4804 includes a list of all ICD-9 code sections backward mapped to the ICD-10 code sections listed in the forward mapping list 4802, along with mapping percentages.
III. Reports
Embodiments of the present disclosure allow a user to view various reports related to any mappings. In some embodiments, the reports section gives the user the following options:
Mapping History Report
Mapping Distribution Report
Mapping Comparison Report
Mapping Across Business Area Report
Mapping Across Version Report
Business Area Wise Mapping Report
Versioning Report
Customized Mapping Report
Published Mapping
Audit Trail Report
Expiry Mapping Details Report
Work Flow Audit Trail Report
1. Mapping History Report—FIG. 49 is an example screen shot 49 of the implementation of a mapping history report 4920 produced by the tool which tracks changes in disease classification code mappings across a selected date range. By entering “from” 4908 and “to” 4910 dates and selecting “search” 4912 in a user interface 4902, the tool produces a mapping history report 4920 as shown by example in FIG. 49. The report 4902 may be generated on the basis of either diagnosis or procedure code, and may be generated based on forward mapping 4904 or backward mapping 4906. In the example shown in FIG. 49, a mapping history report 4902 of forward mapping has been selected. Further details about any code listed in the report 4902 can be viewed upon clicking a code link on the code in the report 4902. FIG. 50 is an example screen shot 50 of a detailed mapping history 5002 about a selected code from the report 4902.
2. Mapping Distribution Report—FIG. 51 is an example screen shot 51 of the implementation of a mapping history report 5102 produced by the tool which shows percentages of disease classification codes across a plurality of different disease classification code categories for a specified business area and a specified disease classification code type. As shown in the example report 5102 illustrated in FIG. 51, the mapping distribution report 5102 shows a percentage of each type of code mapping for any selected business area by diagnosis or procedure. These types of mappings may include: one-to-one unconfirmed, one-to-many unconfirmed, confirmed, customized, and no mapping. By clicking on a corresponding code mapping link, a user can view a more drilled down mapping distribution report particular to that code mapping type. For example, referring to an example screen shot 52 in FIG. 52, a mapping distribution report 5202 is shown specifically for confirmed diagnosis code mappings showing the percentage of types of confirmed code mappings.
FIG. 53 is an example screen shot 53 of a list 5302 of ICD-9 codes and their respectively mapped ICD-10 codes with respect to a selected business area. To export any of the lists of all codes in one code mapping type, a user can choose to export the codes to Excel™, which will show a list of the associated codes, as shown in the report 5402 illustrated in the example screen shot 54 of FIG. 54.
3. Mapping Comparison Report—A mapping comparison report shows results of a reimbursement mapping when a confirmed mapping is different from backward mapping. As illustrated in the example screen shot 55 of FIG. 55, a mapping comparison report 5520 can be provided on a code basis and description basis, e.g., by specifying an ICD-10 code in a dialog box 5504 of a user interface 5502, and/or by using a code lookup feature 5506, and selecting a search button 5508. By checking the box 5510, a list of comparison records is generated.
4. Mappings Across Business Area Report—Referring now to FIGS. 56 and 57, a mappings across business area report may be generated by selecting via a user interface 5602 between forward mapping 5604 and backward mapping 5606, and, when selecting forward mapping as shown in FIG. 56, by entering an ICD-9 code (with or without code lookup 5610), and by selecting a “get equivalent ICD-10 code” button 5612. When selecting backward mapping as shown in FIG. 57, an ICD-10 code (with or without code lookup) is entered, and a “get equivalent ICD-9 code” button is selected. FIG. 57 shows an example of a resulting ICD-10 graphic 5720 identifying the selected ICD-10 code and its corresponding description, and a resulting report 5730 showing ICD-9 codes mapped thereto across various business areas.
5. Mapping Across Versions Report—A mapping across versions report allows a user to view changes in code mappings across different mapping versions. As shown in the example screen shot 58 in FIG. 58, for example, a user interface 5802 illustratively includes a forward mapping button 5804, a backward mapping button 5806 and a reimbursement button 58-8, as well as an ICD code dialog window 5810 and corresponding code lookup feature 5812, and a code equivalent retrieval button 5814. Depending upon the report parameters specified by the user, the tool produces a corresponding report of previous versions of code mappings to the ICD code specified in the user interface 5802. In the example illustrated in FIG. 58, the user has entered forward mapping of ICD-9 code “002.9” in the user interface 5802, and the tool responds by displaying a listing of the corresponding mapped ICD-10 code for each of three different versions 5820, 5830, 5840 respectively. As shown in FIG. 58, the same mapped ICD-10 code “A01.4” is provided for each available mapping version set 2012, 2013, and 2014.
6. Business Area Wise Mapping—Business area wise mapping provides functionality by which user can retrieve mapping records that were confirmed or unconfirmed with respect to a particular business area. FIG. 59 is a screen shot 59 illustrating such a report 5902 generated by the tool which shows details of forward disease classification code mappings in a specified business area. FIG. 60, in contrast, is a screen shot 60 illustrating a report 6002 generated by the tool which shows details of backward disease classification code mappings in a specified business area that is different than that shown in FIG. 59. Illustratively, such reports may be exported using various different formats (e.g., text, excel, and the like).
7. Versioning Report—Versioning reporting can illustratively provide either code versioning or Mapping Versioning reports. A code versioning report provides a user with a detailed analysis (in the form of pie charts, for example) about changes in parameters (such as a percentage of code added, deleted, and descriptions changed) between different mapping set versions. FIG. 61 is an example screen shot 61 illustrating a code versioning report 6102 generated by the tool which shows a comparison of disease classification code modifications made between different disease classification code revisions. Such results can be shown for both diagnosis and procedure codes. To view these reports, a user enters a code type, a first version (such as “2009”) and a second version (such as “2011”). Accordingly, as shown in FIG. 61, two pie charts and are shown for diagnosis and procedure codes respectively, that illustrate data about the number of codes added, removed, and descriptions changed in version 2011 from version 2009.
A mapping version tool provides a user with a detailed list of the changes in the mappings made between selected versions. For example, referring to an example screen shot 62 in FIG. 62, a user interface 6202 illustratively includes inputs for selection of an old version 6204, selection of a new version 6206, whether to include new mappings added 6208, old mappings deleted 6210 and mappings changed 6212, selection of diagnosis code mapping 6214 or procedure code mapping 6216, and forward or backward mapping 6218, and a show report button 6220. For example, as shown in the example screen shot 63 illustrated in FIG. 63, a user has entered an old version “2009” in field 6204, a new version “2010” in field 6206, selected New Mappings Added 6208, Diagnosis Mapping 6214 and Forward Mapping 6218. In response, the tool produces a list 6302 of all new mappings added in the 2010 version which were not present in the 2009 mapping version.
8. Customized Mapping—The customized mapping functionality produces a report of any customized mappings for a selected span of time. As shown in the example screen shot 64 illustrated in FIG. 64, a user interface 4902′, which is similar in most respects to the user interface 4902 illustrated in FIG. 49, illustratively further includes a “get all customized mapping” selection box 6402 which may be used to produce a report of all customized mapping made for backward or forward mappings that meet the remaining report criteria specified in the user interface 4902′. In the example screen shot illustrated in FIG. 65, the user has selected a “From date” of 7/1/2011 and a “To date” 7/20/2011 with respect to forward mapping to retrieve a list of any customized mappings created in that selected time frame. An example of the resulting report 6502 is shown in the example screen shot 65 illustrated in FIG. 65.
9. Published Mapping—The published mapping feature allows a user to view a report displaying all the confirmed codes per business area. Specifically, an administrator may log in, and from the example screen shot 66 shown in FIG. 66, the administrator may select the business area “Enterprise”, for example. The administrator may select to view confirmed procedure codes or confirmed diagnosis codes in an adjacent dropdown menu, and by clicking on a view report button, a user can view all confirmed ICD diagnosis code forward mappings for the Enterprise business area. A user could view the same for backward mappings as well. An example report 6602 is shown in FIG. 66 for the Enterprise business area and for diagnosis codes.
10. Third Party Audit Trail Report—Referring to an example screen 67 shot shown in FIG. 67, a third party audit trail report 6710 shows audit details of service consumption, such as which third party application consumed the service, how many translations were done, and the like. An allocator can view audit trail details of a selected user (medical code, approver, etc.). The user may specify a configuration of the report 6710 by selecting a desired date range using date range fields 6704 and 6706, and by selecting “search” button 6708, all provided in a user interface 6702. FIG. 68 is a screen shot 68 illustrating an example report 6802 showing details of disease classification codes included in one such audit trail report generated by the graphic user interface of FIG. 67.
The reports to allocation page integration feature allows a user to integrate a report with an allocation page for both types of GEMs mappings, and may be restricted to view by an allocator. The reports integrated with the allocation page include a mapping distribution report for forward and backward mappings, a code distribution report for payers, and a code distribution report for providers. Specifically, an allocator may login, navigate to the “Payer Data Analyzer” section, and click on “Claim Code Distribution” for forward mappings. By selecting forward mapping 6904, backward mapping 6906, medical coder 6908 and approver 6910 in a user interface 6902, and thereafter selecting “search” 6912, a report 6920 is generated of a corresponding ICD code list common to the selected medical coder and approver. When a user wishes to view a report, an Allocate button 6930 will be selected and the user will be redirected by the tool to a task allocation page with the ICD-9 codes listed on the report 6920. A user can use this functionality for a mapping distribution report and code distribution report for a provider.
11. Expiry Mapping Details Report—The expiry mapping details functionality provides a user with a list of any code mappings that are expired or are going to expire in a selected time period. As shown in an example screen shot 70 in FIG. 70, a user can select in a user interface 7002, for forward mapping 7004 or backward mapping 7006, a particular month in a drop down menu 7008 to view any subject reports for that selected month. The user also has the option to select a date range (using fields 7010 and 7012) to view any qualifying reports, and a search button 7014 is provided to cause the tool to generate the expiry reports. FIG. 71 is an example screen shot illustrating an example expiry report 7020.
12. Work Flow Audit Trail Report—The Work Flow Audit Trail Report displays any activities performed for a code mapping/translation. For example, as shown in the example screen shot 72 in FIG. 72, the report 7202 lists details concerning a particular code and mappings related to that code. FIG. 73 is an example screen shot 73 illustrating the tool's functionality showing a report 7302 listing all codes' activities within a specified date range.
IV. Data Analytics
According to embodiments of the present disclosure the tool includes a data analytics feature which includes a Payer Data Analyzer feature and a Provider Data Analyzer feature.
A. Payer Analytics
The Payer Data Analytics feature of the tool analyzes healthcare payer data and produces the follow reports relating to such analysis of healthcare payer data:
1. Upload claims
2. Claims Historical Data
3. Mapping Distribution Report
4. Claims Amount Distribution
5. Claims Conversion Distribution
6. Code Distribution
7. Provider Comparison
8. Claims Summary
9. Claim Audit Trail Report
1. Upload Claims—The upload claims feature provides forward mapping (ICD-9 to ICD-10) as well as backward mapping (ICD-10 to ICD-9) conversion for the uploading of processed medical claims. FIG. 74 is an example screen shot 74 illustrating an upload claims user interface 7402 for entering claims information. For forward claims processing, in the embodiment shown, a user can select radio button “ICD-9 Claims” 7404 and for backward claims processing, a user can select “ICD-10 Claims” 7406. After browsing for the input claims data file and entering the file in the dialog box 7408, including specifying a file description in a file description field 7410, the claims file can be processed by clicking a “Process Claims File” button 7412. After successful processing (i.e., the forward or backward mapping) of the input claim file, the current files (including success and error files) can be downloaded by clicking on the particular file link 7502 as shown in the example screen shot 75 of FIG. 75. Alternatively or additionally, an error file may also be downloaded by clicking on the error file link 7504. After processing the claim files, an email is generated and sent to the all active users by the administrator. A copy of the email is also sent to the administrator.
An accepted format for the claims data can be retrieved and viewed by clicking on a claims format link. In the example shown, an acceptable format for a forward mapping for payer claims contains information including provider details, claim diagnosis and procedure codes, claim charged amounts and paid amounts, and claim number. Examples showing payer claims formats for forward and backward mapping inputs and corresponding outputs can be found in the parent application, U.S. Patent Application Ser. No. 61/834,908, the disclosure of which has been incorporated herein by reference in its entirety.
2. Claims Historical Data—FIG. 76 is an example screen 76 shot of a home page for the claims historical data feature. Specifically, the tool performs data analytics for both diagnosis and procedure codes. For example, via a user interface 7602, a user can select diagnosis 7604 or procedure code 7606, enter an ICD-10 code (using a code lookup feature 7610 if desired), select a particular business area, i.e., line of business (LOB) 7612 and State 7614, and generate the report by selecting “Search” 7616. With this feature, a user can view frequency analysis results for a particular line of business (“LOB”) and within a particular State, or for all input data that has been uploaded.
This feature can also provide a percentage of the use of a particular code. As shown in an example screen shot 77 in FIG. 77, the tool produces a graphic 7702 of the selected ICD-10 code and a report 7704 of the matching ICD-9 codes in historical claims data. The illustrated usage percentage in the claims historical data report 7704 can be represented as the occurrence of a particular ICD-9 code related to a particular ICD-10 code. Also, it provides a highlighted code 7706 representing a reimbursement mapping code provided by CMS.
3. Mapping Distribution Report—The mapping distribution report provides a percentage of each type of mapping (e.g., one-to-one and one-to-many mapped codes) in the files uploaded in a batch process, for example. Referring to an example screen shot 78 shown in FIG. 78, a user selects a file 7804 for which a mapping distribution is sought. The user can then select a provider 7806, a code type diagnosis/procedure 7808 and a State 7810 for which a result is to be displayed. The user can then click the “View Report” button 7812 to view the resulting mapping distribution report 7802 produced by the tool. The mapping distribution report 7802 can be exported to different formats including but not limited to XML, CSV, Acrobat Reader (.pdf), MHTML, Word, Excel, and TIFF.
4. Claims Amounts Distribution—The Claim Amount Report shows a claim amount distribution. Referring to an example screen shot 79 illustrated in FIG. 79, the report 7902 shows two pie charts: a “Total Charged Amount for Claims” chart and a “Total Paid Amount for Claims” chart. The “Total Charged Amount for Claims” chart provides details about a total charged amount for claims by a selected provider in a selected state. The “Total Paid Amount for Claims” chart displays details about a total paid amount for claims for a particular provider in a particular state. Claim amount reports can be exported to different formats including but not limited to XML, CSV, Acrobat Reader (pdf), MHTML, Word, Excel, and TIFF.
5. Claims Conversion Distribution Report—The claims conversion distribution report gives details about all the mappings resulting from a successfully processed file. Referring to an example screen shot 80 illustrated in FIG. 80, graphical representations for one-to-one, one-to-one clusters, one-to-many, one-to-many clusters, no mappings, and one-to-one clusters overflow are included in the example claims conversion distribution report 8002. The claim conversion distribution report 8002 can be exported to different formats like XML, CSV, Acrobat Reader (pdf), MHTML, Word, Excel, and TIFF.
6. Claims Code Distribution Report—Referring to an example screen shot 81 illustrated in FIG. 81, the illustrated claims code distribution report 8102 shows details as per specific mapping type 8104 (i.e. one-to-one, one-to-one cluster, one-to-many, one-to-many cluster, no mappings and not found). This report also shows codes included in the mapping. Claims code distribution reports can be exported to different formats including but not limited to XML, CSV, Acrobat Reader (pdf), MHTML, Word, Excel, and TIFF.
7. Provider Comparison Report—The provider comparison report displays maximum and minimum one-to-one or non one-to-one mappings in a particular state. The sort order decides the top and bottom five providers which provide maximum one-to-one or non one-to-one mappings.
The provider comparison report tool provides reports according to three types: by codes, by claims, and by claims amount. Referring to an example screen shot 82 illustrated in FIG. 82, a user can view maximum or minimum, one-to-one or non one-to-one mapped code, per provider for a particular code. The example shown in FIG. 82 is for a minimum one-to-one mapped comparison between two providers. Referring to an example screen shot 83 shown in FIG. 83, a provider comparison report by claims 8302 can show a maximum or minimum, one-to-one or non one-to-one mapped claims report for different providers for a particular claim.
Referring now to an example screen shot 84 illustrated in FIG. 84, a comparison by claims amount report 8402 can show a maximum or minimum, one-to-one or non one-to-one mapped claims amount provided by different providers for a particular code. The example in FIG. 84 shows two charts: a provider payment amount comparison chart, and a provider charge amount comparison chart. Specifically, the provider payment amount comparison chart shows payment amount per provider. Likewise, the provider charged amount comparison chart shows an amount charged by each provider.
8. Claims Summary—The Claims Summary report provides summary results of all the files which are processed through a batch process. As shown in the example screen shot 85 in FIG. 85, the tool lists information in the report 8502 such as the total number of claims processed, total successfully processed claims, total charge amount($), total payment amount($), top 50 providers processed claims, top 50 providers successful claims, top 50 providers processed claims ($), top 50 providers payment amount (percentage to top 50 providers charge amount)$, total number of diagnosis codes, total number of procedure codes, distinct diagnosis Codes, and distinct procedure codes.
9. Claims Audit Trail Report—The claims audit trail report provides a detailed description of claims requests for a given period of time. A user can provide date ranges between which a result is desired. As shown in the example screen shot 86 in FIG. 86, this report 8604 is selectively produced based on information provided by a user via a user interface 8602, and gives details like claim file name, total number of claims processed, total number of successful claims and total number of error claims. As shown in FIG. 86, a user can click on one of these aforementioned numbers, and a popup window may open showing a detailed listing of all of the claims in that particular list. For example, as shown in a screen shot 87 illustrated in FIG. 87, a user has clicked on a total number of successfully processed claims in the report 8604 of FIG. 86, and the resulting report 8702 produced by the tool shows a listing of the individual claims which are successfully processed. When the user clicks on a particular errored claim, a popup will open which will show claims that were not processed. In each of these popups, at the left hand side a “View Codes” link is provided, which, upon clicking, will display a list 8802 of the selected codes, an example screen shot 88 of which is shown in FIG. 88.
B. Provider Analytics
The Provider Data Analyzer tool operates similarly to the Payer Data Analyzer tool, except its functionality is advantageous to providers in that it provides information related to healthcare payer organizations. For example, this tool includes one or more of the following functions and/or reports:
1. Upload claims
2. Claims Mapping Distribution
3. Payer Comparison
4. Claims Summary
5. Claim Audit Trail
1. Upload Claims—The upload claims feature provides forward mapping (ICD-9 to ICD-10) as well as backward mapping (ICD-10 to ICD-9) conversion for the uploading of medical claims. FIG. 89 is an example screen shot 89 illustrating an upload claims user interface 8902 for entering claims information. For forward claims processing, in the embodiment shown, a user can select radio button “ICD-9 Claims” 8904 and for backward claims processing, a user can select “ICD-10 Claims” 8906. After browsing for the input claims data file and entering the file in the dialog box 8908 (and/or using the browsing feature 8910), including specifying a file description in a file description field 8912, the claims file can be processed by clicking a “Process Claims File” button 8914. After successful processing (i.e., the forward or backward mapping) of the input claim file, the current files (including success and error files) can be downloaded by clicking on the particular file link 9002 as shown in the example screen shot 90 of FIG. 90. Alternatively or additionally, an error file may also be downloaded by clicking on the error file link 9004. After processing the claim files, an email is generated and sent to the all active users by the administrator. A copy of the email is also sent to the administrator.
An accepted format for the claims data can be retrieved and viewed by clicking on a claims format link. An acceptable format for a forward mapping for payer claims illustratively contains information including the following:
Provider details
Payer details
Claim Diagnosis and procedure codes
Claim charged and reimbursed amounts
Claim number
Hospital details
State Code
Admit Date
Discharge Date
Medicare Number
Medicaid Number
Health Plan Id
Type of Insurance
Net charge amount
Total amount
Similar to forward claims format, a provider claims backward input file format illustratively contains information including:
Provider details
Payer details
Claim Diagnosis and procedure codes
Claim charged and reimbursed amounts
Claim number
Hospital details
State Code
Admit Date
Discharge Date
Medicare Number
Medicaid Number
Health Plan Id
Type of Insurance
Net charge amount
Total amount
Co-insurance amount
Examples showing provider claims formats for forward and backward mapping inputs and corresponding outputs can be found in the parent application, U.S. Patent Application Ser. No. 61/834,908, the disclosure of which has been incorporated herein by reference in its entirety.
2. Mapping Distribution Report—The mapping distribution report enables a user to understand various levels of distribution between the existing ICD-9 codes received and their respective ICD-10 codes into different categories, such as one-to-one, one-to-one cluster, one-to-many mapped codes, no map and not found. The mapping distribution report provides a percentage of each type of mapping (e.g., one-to-one and one-to-many mapped codes) in the files uploaded in a batch process, for example.
3. Paver Comparison Report—The payer comparison report provides maximum and minimum one-to-one or non one-to-one mappings in a particular state. The sort order decides the top and bottom five payer which provide maximum one-to-one or non one-to-one mappings. In one embodiment, the payer comparison report tool provides three types of comparison reports: by codes, by claims, and by claims amount. A user can view maximum or minimum, one-to-one or non one-to-one mapped code, per provider by codes. Referring to an example screen shot 91 illustrated in FIG. 91, the illustrated report 9102 shows a minimum one-to-one mapped comparison among three payers by code. Referring to an example screen shot 92 shown in FIG. 92, a payer comparison report by claims 9202 can show a maximum or minimum, one-to-one or non one-to-one mapped claims report for different payers by claims. As shown in FIG. 92, the report 9202 illustrates a one-to-one mapped comparison among three payers.
Referring now to an example screen shot 93 illustrated in FIG. 93, a comparison by claims amount report 9302 can show a maximum or minimum, one-to-one or non one-to-one mapped claims amount provided by different providers for a particular code. This example report 9302 shows two charts: a payer reimbursed amount comparison chart, and a payer charged amount comparison chart. Specifically, the payer reimbursed amount comparison chart shows payment amount vs. payer. Likewise, the payer charged amount comparison chart shows a charged amount vs. payer.
4. Claims Summary—The claims summary report provides results of the files which are processed through the batch process. As shown in the example screen shot 94 illustrated in FIG. 94, the claims summary report 9402 provides information such as the total number of claims processed, total successfully processed claims, total charged amount, total payment amount, top 50 providers processed claims, top 50 providers successful claims, top 50 providers processed claims, top 50 providers payment amount (percentage to top 50 providers charge amount), total diagnosis codes, total procedure codes, distinct diagnosis codes, and distinct procedure codes.
5. Claims Audit Trail Report—This report is similar to the audit trail functionality referred to above with respect to FIGS. 86-88. The claims audit trail report provides a detailed description of claims requests for a given period of time. As shown in the example screen shot 95 illustrated in FIG. 95, the claims audit trail report 9502 gives details like claim file name, number of claims processed, successful claims and error claims, all based on information provided via a user interface which may illustratively be identical or similar to the user interface 8602 illustrated in FIG. 86. In any case, a user can click on a claim number within the report 9502 and a popup will open which will show the selected claim number.
Referring now to an example screen shot 96 illustrated in FIG. 96, when a user clicks on a particular successful claim, a popup window 9602 shows claims that were successfully processed. When the user clicks on an errored claim, a popup window will open which will show detail about the claims that were not successfully processed. In each of these popups, at the left hand side a “Views Codes” link is provided, which, upon clicking, will display a list 9702 of the selected codes, an example screen shot 97 of which is shown in FIG. 97.
Referring to example screen shots 98 and 99 illustrated in FIGS. 98 and 99 respectively, the reports to allocation page integration feature allows a user to integrate a report with an allocation page for both types of GEMs mappings, and may be restricted to view by an allocator. The reports integrated with the allocation page include a mapping distribution report for forward and backward mappings, a code distribution report for payers, and a code distribution report for providers. An example code distribution report 9802 for providers is illustrated in FIG. 98. When a user wishes to view a report, an Allocate button 9804 will be selected and the user will be redirected by the tool to a task allocation page with the ICD-9 codes listed on the report. The report is integrated with an allocation page include a mapping distribution report for forward and backward mappings, a code distribution report for payers, and a code distribution report for providers. An example is illustrated in the screen shot 99 of FIG. 99. Specifically, an allocator may login, navigate to the “Payer Data Analyzer” section, and click on “Claim Code Distribution” for forward mappings. By selecting forward mapping 9904, backward mapping 9906, priority 9908, Search type 9910 and description 9912 in a user interface 9902, and thereafter selecting “search” 9916, a report 9920 is generated of a corresponding ICD code list common to the selected medical coder and approver, or all codes if the all codes button 9914 in the user interface 9902 is selected. When a user wishes to view a specific report, an Allocate button 9922 will be selected and the user will be redirected by the tool to a task allocation page with the ICD-9 codes listed on the report 9920.
V. Searching
Embodiments of the present disclosure employ search functionalities, an example of which is shown in the example screen shot 100 illustrated in FIG. 100. A search can be performed on both diagnosis 10004 as well as on procedure codes 10006. For example, a user can enter the description keyword “Tuberculoma” in the code description field 10008 for a diagnosis code 10004 and select the Search button
10010. All ICD-9 as well as ICD-10 codes whose description containing the word “Tuberculoma” will be displayed. Another example using the description keyword “heart” is shown in the example screenshot 101 illustrated in FIG. 101, which produces lists 10102 and 10104 of ICD-9 and ICD-10 codes relating to the entered search term. It should be noted that a search can also be performed by a tag associated with a particular ICD code.
Using the linking of GEMs mapping from the Search Code functionality, when a code is selected, the system shows all mappings related to that code. In the example screen shot 102 illustrated in FIG. 102, the search feature includes a user interface 10202 which provides for selection of forward mapping 10204, backward mapping 10206 or reimbursement mapping 10208, input into a field 10210 of an ICD-9 code (optionally using a code lookup feature 10212) and a “get equivalent ICD-10 code” button 10214. Input of an ICD-9 code, e.g., 944.20 as illustrated in FIG. 102, the tool produces a graphic 10220 of the selected ICD-9 code and its textual description, and a list 10230 of all ICD-10 codes corresponding to the specified ICD-9 code. Mapping histories of selected ICD-9 codes may be selectively viewed using a “view mapping history” feature 10216 of the user interface 10202. On the other hand, for backward mapping, if a user may select an ICD-10 code, e.g., L02.511 as illustrated in the screen shot 103 illustrated in FIG. 103, and the tool will then show a graphic 10320 of the selected ICD-10 code and its textual description, and a list 10330 of all ICD-9 codes corresponding to the specified ICD-10 code.
VI. Workflow Management
According to embodiments of the present disclosure, the disease classification code mapping tool includes an workflow management feature which is illustratively divided according to roles including: super administrator, allocator, first and second level approvers, medical coder, and the like. These roles basically work on two modes: GEMs (all the results are generated on the basis of GEMs files provided by CMS), and Specific mode (all the results are generated on the basis of codes provided by the organization and both are isolated from each other).
The translator tool provides multiple levels of access for different user roles. For example, a user can access the system (or be restricted to access) as one or more of the following types of users: super administrator, administrator, allocator, first level approver, second level approver or medical coder.
The super administrator can perform the following tasks: administration, configure, mapping, report, and search.
Referring to an example screen shot illustrated in FIG. 104, the main menu is shown in which the application mode 420 is selected to be Specific and the business area is selected to be ICD-10. In this mode, the administration functionality allows a user (e.g., super administrator) to create another user and assign that user with a business role (e.g., allocator, approver, medical coder and/or business user), and business areas that the new user can work in. As illustrated in FIG. 105, when the super administrator chooses to create a user, a user creation window 105 opens. For new user creation, the super administrator enters the following details of the new user into a user creation interface 10502: first name, last name, userId, password, confirm password, email ID, business role, and business area. The super administrator further enters a business role of the new user into the interface 10502, e.g., as an allocator, an approver (first or second level), a medical coder or a business user. A user listing 10504 is illustratively provided via which the super administrator may edit existing user information.
Upon successful user creation, an account creation mail is automatically generated and sent to administration by the super administrator. The user gets account details when the business area is allocated to him. Different email templates are sent based on the user roles. Similarly, if user information is updated (like active/inactive status is changed), the super administrator sends an email to the user regarding the update in user's profile information.
As shown in the example screen shot 106 illustrated in FIG. 106, the super administrator can create or view a hierarchy by selecting the build hierarchy link 10602 located above the users list 10504. A hierarchy refers to an organizational structure depicting the relationships between types of users (e.g., administrator, allocator, approver, medical coder, and the like). For example, as shown in the example screen shot 107 illustrated in FIG. 107, the super administrator can select a particular business area 10702 and an allocator 10704, which will provide list 10708 of approvers and medical coders associated with the selected allocator 10704 for the selected business area 10702. A similar user interface can be provided to allow the super administrator to select first and second level approvers for selected business areas and corresponding assigned allocators.
When the hierarchy is successfully built, an allocation email is automatically generated and sent to the users (e.g., allocated medical coders and approvers) by the super administrator. A copy is sent to the allocator as well.
The configure, mapping, report, and search features operate in a similar manner as discussed above. For the specific functionality, the super administrator may need to upload a specific codes file for which a mapping is required. Respectively, these features will give results for specific code files previously uploaded by the super administrator.
Allocator:
With respect to the approval workflow tool, an allocator can perform tasks including one or more of: configure, task allocation, mapping, report, and search.
Configure—This functionality operates in a similar manner as discussed above with respect to the super administrator.
Task Allocation—The allocator task allocation functionality may be divided into four categories: (1) create task, (2) transfer task, (3) manage task, (4) and task status.
Create Task—Referring now to the example screen shot illustrated in FIG. 108, an allocator can create a task in a task allocation menu 10802 to allocate codes to an approver and a medical coder for forward mapping 10806 or backward mapping 10808 via a user interface 10804. The allocator provides a type 10810, description code range 10812 or selecting an option referred to as “Get All Codes” 10816, and then selecting “search” 10814. The allocator can then select particular codes to assign to an approver and medical coder from a resulting list of ICD-10 codes 10820 produced by the tool, and can further select an approver 10840 and a medical coder 10850, with or without comments 10830, relating to creating or modifying mappings for selected ICD-10 codes. By clicking on “allocate” 10860, code mapping assignments relating to the selected ICD-10 codes will be allocated to the selected medical coder and the selected approver. A list 10870 of approvers assigned to selected ICD-10 codes may be produced by the tool.
Referring now to the example screen shot 109 illustrated in FIG. 109, for a specific mode, a priority option 10908 is provided in a user interface 10902 for allocating tasks relating to forward 10904 or backward 10906 mapping. The user interface 10902 may further include a search type field 10910, a skill set field, e.g., heart, 10912, and a search button 10914 as well as a “get all codes” button 10916. If a user wishes to allocate the codes according to a certain priority (e.g. highest, medium or low) this can be specified via appropriate selection from the priority option menu 10908; otherwise the user can select “All” to get all codes.
Once the codes are allocated, an email is automatically generated and sent to the coder and approver by the super administrator. A copy is also sent to the administrator and allocator.
Task Allocation—The allocator may allocate tasks by functional group, and a user interface 11002 for accomplishing this is illustrated in the example screen shot 110 of FIG. 110. The user interface 11002 includes forward 11004 and backward 11006 mapping options, as well as a priority menu 11008, a search type menu 11010 and a functional group menu 11012. By selecting functional group as the search type, a functional group may be specified from the menu 11012 to search, using the search button 11014, for tasks to allocate to medical coders and/or approvers by functional group as illustrated in the example screen shot 111 illustrated in FIG. 111. Optionally, the allocator can also select “get all codes” 11016 to retrieve all ICD codes associated with the selected search parameters. Additionally, the allocator may assign groups of codes in one go by selecting the search button 11014 after selecting a functional group, in which case the tool illustratively produces the grid of codes 11202 which are related to the selected functional group and which further illustratively includes an items per page pull-down menu 11204. Illustratively, by default grid contains a modest number, e.g., 10, records per page. However, using the menu 11204, the allocator can select any number of ICD code records to display per page. Illustratively, the minimum number of records per page may be 10 and the maximum may be 500, although these values may be varied as desired. In any case, the option to increase the number of ICD code records per page allows the allocator to group large numbers of records together for allocation without having to manually advance through any, or fewer, ICD grid pages. As described above, the allocator may then enter comments relating to task allocations in a comment field 11206, and may select an approver using a pull-down menu 11208 and a medical coder using a pull-down menu 11210. Additionally, as illustrated in the example screen shot 113 illustrated in FIG. 113, the grid of codes 11202 illustrated in FIG. 112 displays a grid of codes 11302 which includes an additional functional group column which identifies various functional groups associated with each listed ICD-9 code.
When ICD codes are uploaded by functional groups as just described, there may be cases where the ICD codes can be common across different functional groups. Illustrated in the screen shot 114 of FIG. 114 is an example list of such overlapping codes identified in a particular functional group. The tool illustratively includes functionality to re-allocate such ICD codes into the workflow for the different functional group and run the workflow. In one embodiment, the first assignment of a code in overlapping functional groups to a medical coder will identify the medical coder that performs the mapping, and the second assignment will identify another medical coder that has only viewing privileges for the mappings but not editing privileges. The same will be applicable as between an assigned approver level 1 and an assigned approver level 2. In either case, the medical coders and approvers will illustratively have 2 grids displayed; one with codes to be mapped by the medical coder, and the other with codes allocated to another medical coder for mapping but viewable by the first medical coder. The same hierarchy is illustratively implemented with respect to approver levels 1 and 2. In any case, once and code is allocated, an email is automatically generated and sent to the medical coder and approver by a super administrator, and a copy is also sent to the administration and allocator. An example of such an email 11502 is shown in the example screen shot 115 illustrated in FIG. 115. In the illustrated example, the email 11502 illustratively includes a table of code assignments 11504.
Transfer Task—The allocator can reallocate, or transfer, codes for a medical coder or an approver. Specifically, to pull a task from a medical coder or an approver, the allocator can select a business area, and select the medical coder or the approver whose tasks the allocator wants to reallocate to other resources.
Referring now to the example screen shot 116 illustrated in FIG. 116, the allocator may select particular codes and assign them, for forward 11604 or backward 11606 mapping, to a medical coder 11610 or approver 11612 in a selected business area 11608, via a user interface 11602. In the illustrated example, a medical coder 11610 is selected for the task transfer, and the tool accordingly modifies the user interface 11602 to produce a medical coder pull down menu 11614 which may be used to select a desired medical coder whose current code mapping assignments are to be viewed, one or more of which may be transferred to another medical coder. When the “get task” button 11616 is selected, the tool produces the corresponding list 11620 of codes, and the allocator can select the mapping task of one or more codes from the list 11620 to transfer, e.g., with or without comments 11630, to another medical coder which may be selected using the pull down menu 11640. By clicking on “Transfer Task” 11650, selected codes will be re allocated to the selected medical coder or approver or to an already assigned approver. The tool can also serve to prevent a medical coder and approver from being the same for a single code or task.
When the task is reallocated, an email is automatically generated. The email is sent to approve a medical coder to whom the task is reallocated from the administrator. A copy of an email is also sent to the allocator and the administrator.
Manage Task—An allocator can also manage tasks. For example, as shown in the example screen shot 117 illustrated in FIG. 117, the allocator can unconfirm particular mappings, e.g., forward 11704 or backward 11706 mappings, before their end date via a user interface 11702. The allocator or other user, e.g., administrator, can search the mapping by code, by description, or can search for all mappings through pull down menu 11710. Selecting “search” 11712 will produce a list 11720 of corresponding ICD codes. If the “Get All” option is selected, all mappings will be displayed in the list 11720. The allocator can then selectively unconfirm a mapping by clicking the “unconfirm” button, e.g., 11722, adjacent to the code in the list 11720. Upon making the unconfirm selection, the allocator may be prompted to specify the reason for unconfirming the code.
After a user unconfirms any mapping, an email is automatically generated and sent to the allocator, approver and medical coder who have done this particular mapping. A copy is also sent to the administrator. A copy of the email may also be marked to the business user for the department.
Task Status—FIG. 118 is an example screen shot 118 of a process by which an allocator can retrieve a task status. In some embodiments, by selecting a particular department, the allocator can get a task's status report. In this example, a user interface 11802 includes selections 11804 and 11806 for ICD-9 and ICD-10 diagnosis codes respectively, an allocator selection menu 11808, a business area selection menu 11810 and a “get report” button 11812. The tool illustratively produces three reports from which the allocator can choose: a coder wise report 11820, an approver wise report 11830 and a client approver wise report 11840. These reports contain information including the medical coder/approver name, number of codes assigned, number of codes approved, number of pending codes to process, number of rejected codes, and number of codes pending approval. By clicking on the corresponding numbers, an allocator can get a more detailed report as shown in the report 11902 illustrated in the example screen shot 119 of FIG. 119.
Mapping, Report, and Search—The mapping, report, and search features operate in a similar manner as discussed above. For the specific code option, the super administrator may need to upload a specific codes file for which a mapping is required. Respectively, these features will give results for specific code files previously uploaded by the super administrator.
Medical Coder Tasks:
With respect to medical coders, allocators can perform tasks including: work list, report, and search.
Work List—Referring now to the example screen shot 120 illustrated in FIG. 120, the work list tool is divided into three parts: work list 1904, pending list 12006, and rejected list 12008 for a selected mapping type 12002. The work list feature produces a list 12010 of details about numbers of the assigned codes to be processed. As soon as any code is processed, it will be dropped into the “pending list.”
Pending List—Referring to the example screen shot 121 illustrated in FIG. 121, the pending list 12102 provides details about any codes processed by a medical coder that are awaiting approval.
Rejected List—Referring to the example screen shot 122 illustrated in FIG. 122, the rejected list 12202 provides gives details about all the codes that have been rejected by the approver.
Escalated List—If the medical coder is assigned a code that is outside of the medical coder's expertise, the medical coder can escalate that code to an approver to reassign to another medical coder.
Approver—level 1:
With respect to the approval workflow, an approver can perform tasks including: work list, report, and search. The work list feature is divided into four parts: pending list, approved list, escalated list, and completed work list.
Escalated List—Referring now to the example screen shot 123 illustrated in FIG. 123, the approver worklist includes a pending list 12304, an approved list 12306, an escalated list 12308 and a rejected list 12310, all for a selected mapping type 12302. In the example illustrated in FIG. 123, the Escalated List 12308 is selected, and the tool produces a corresponding escalated list 12320 adjacent to the worklist. The escalated list includes a functional group pull down menu 12330 via which the approver can select a desired functional group. Once selected, the escalated list 12320 contains details about all of the codes which are assigned to another medical coder. The approver can click on a hyperlink of a code in the list 12320, and this action illustratively produces the text box 12402 illustrated in the example screen shot 124 of FIG. 124. Using this text box 12402, the approver can select an alternate medical coder 12406 to whom to reassign the selected code, with or without providing a written reason 12404, and by clicking the “reassign” button 12408 the task in the escalated list 12320 is reassigned to the selected medical coder. Optionally, the approver can upload a reference document 12410 relating to the reassigned code.
Rejected List—Referring now to FIG. 125, an example screen shot 125 of the approver worklist is shown in which the Rejected list 12310 option is selected, producing the rejected list 12502. By selecting a functional group using the pull down menu 12330, the rejected list 12502 contains details about all of the codes having a mapping that has been rejected. The approver level 1 can select a correct mapping and then save the correct mapping. By so doing, the tool will automatically move the formerly rejected code to the approved list 12602 as illustrated in the example screen shot 126 illustrated in FIG. 126.
Approved List—Referring now to the example screen shot 127 illustrated in FIG. 127, the approved list available to the approver level 1 includes details about all of the codes which are assigned to the approver level 2, and an example of such a list of codes 12710 is shown in FIG. 127. The second level approver worklist includes a work list 12704 and a completed list 12706, for all assigned forward and reversed mappings 12702. The codes in the list of codes 12710 in the approver level 2 worklist move to the completed work list 12706 upon approval by the approver level 2. After approving, the code is removed from the approved list of the approver level 1.
Pending List—Referring now to the example screen shot 128 illustrated in FIG. 128, the approver pending list 12802 is shown for a selected mapping type 12302 and for a selected functional group 12330. The pending list 12802 gives details about all the codes that are pending for approval. The approver can approve or reject each of the mappings by clicking on the appropriate approve/reject button. Illustratively, the tool may include a feature by which the approver can select and approve a plurality of records at a time, e.g., 10 records, by clicking the “Approve All” button 12804. After approving or rejecting any code, an email is automatically generated and sent to the medical coder to whom was given the task from the administrator. A copy is also sent to the administrator and his allocator.
Approver—level 2:
With respect to the approval workflow, an approver level 2 can perform tasks including: work list, report, and completed list.
Work List—Referring to the example screen shot 129 illustrated in FIG. 129, an approver level 2 worklist includes a Work List 12704 and a Complete list 12706 for each mapping type 12702. An example Work List 12902 is shown in FIG. 129 for a selected functional group 12330, and the list 12902 is a list of all mappings that are approved by a level 1 approver for the selected functional group.
Complete List—Referring now to the example screen shot 130 illustrated in FIG. 30 an example Complete List 13002 is shown for a selected functional group 12330. The Complete List 13002 provides a list of all mappings that are approved by a level 1 approver and confirmed by all approvers from the selected business area.
With respect to an iteration cycle in workflow, an approver can reject a code a specified number of times (e.g. three). At that point, the approver will have to map the code and confirm the mapping (i.e., the rejection option would be disabled). Specifically, referring now to the example screen shot 131 illustrated in FIG. 131, an approver could login and attempt to reject the same code in a pending list 13102 more than three times. Consequently, the approver will get an error message produced by the tool indicating that the approver cannot reject a mapping more than three times. The approver may then select the approve all button 13104 to approve all such codes or approve each such code individually by selecting the code and clicking the approve button.
Report and Search
The report and search features operate in a similar manner as discussed above. For specific mode, the super administrator may need to upload a specific codes file for which a mapping is required. Respectively, these features will give results for specific code files previously uploaded by the super administrator.
Future Mappings
According to embodiments of the present disclosure, referring now to example screen shots 132 and 133 illustrated in FIGS. 132 and 133 respectively, the tool illustratively allows a user to reallocate or confirm code that is already confirmed within the same department, but with a different effective date. In other words, the tool allows users to set mappings that will only become effective at a future date. A user interface 13202 is provided via which the user may select an ICD-9 code of a specified code type, and then select “get equivalent ICD-10 code.” A graphic 13220 of the selected ICD-9 code and its textual description are provided, as well as a table 13230 of mapped ICD-10 codes. A color code table 13240 is illustratively included to distinguish between ICD-10 codes having similar forward and backward mappings (e.g., rows in the ICD-10 table shaded yellow) and ICD-10 codes having different forward and backward mappings (e.g., rows in the ICD-10 table shaded green). A future mappings list 13250 is also shown which lists ICD-10 codes which are already confirmed within the same department.
Multiple Confirmations of Code—This feature allows a user to allocate a code which is already confirmed. The code can again be assigned through the workflow for mapping and future confirmations. Using this feature, a user can have an ICD-9 code mapping to different ICD-10 codes for different spans of time. For example, an ICD-9 code “014.80” maps to an ICD-10 code of “A18.32” or “A18.39.” During the initial workflow, it was confirmed that the ICD-9 code “014.80” maps to an ICD-10 code “A18.32” from the date Mar. 30, 2012 to Jun. 30, 2012. Then however, the user can run the workflow over again anytime before Jun. 30, 2012 and fix a future map for the ICD-9 code “014.30” before the mapping expires. In the example screen shot 133 illustrated in FIG. 133, the future mapping list 13302 lists ICD-10 codes which are confirmed in the same department but which have different effect dates, e.g., 3/31/2012-6/30/1012 and 7/1/2012-7/22/2012 for the same code A18.32. The tool illustratively has validation to avoid such overlapping dates.
Referring to the example screen shot 134 illustrated in FIG. 134, an allocator can login, go to task allocation, create task, and select an ICD code 13404, 13406, 13408, 13410 from a user interface 13402 and select “get mappings” 13412, and list of codes 13420 is produced, one or more of which may be assigned to the medical coder. Then the medical coder can go to the work list, and click on the assigned ICD code. The medical coder can then work on that task, do the appropriate mapping, and save the mapping with a justification. This will send the task (e.g., the ICD code) to the approver. Now, referring now to the example screen shot 135 illustrated in FIG. 135, an approver can login by and go to the work list and approve the same task with certain effective dates. The allocator can login to see a list 13502 with the same code that the approver had just approved, and subsequently confirm the code with different effective start and end dates.
Coder Support Documents—This feature allows a coder and an approver to upload a reference document which has been referenced while code mapping. Also, the user can view the document by downloading the reference document.
A user can login as a medical coder and go to the work list, click on any code. The tool will redirect the coder to the mapping page, where the coder can click on “save” after selection of an appropriate mapping. Referring to the example screen shot 136 illustrated in FIG. 136, a popup window 13602 illustratively appears with a reason field 13604 and a save button 13606. Illustratively, the user can click on the “Upload Reference Document” button 13608 to upload the document. Referring now to the screen shot 137 illustrated in FIG. 137 a list 13702 is display which contains links to all uploaded reference documents. The user can download any document in the list 13702 by clicking on a corresponding View/Download link.
The report and search feature operate in a similar manner as discussed above. For “Specific”, the super administrator may need to upload a specific codes file for which a mapping is required. Respectively, these features will give results for “Specific” code files previously uploaded by the super administrator.
Reverse Map—While defining forward mappings, the backward mappings leading to the source ICD-9 code are illustratively visible, so that a user can analyze and confirm the forward mappings within the tool. The same applies while defining backward mappings. Referring to an example screen shot 138 illustrated in FIG. 138, a user can fetch all the ICD-10 codes which map to the ICD-9 codes originally entered by the users by querying the backward mapping table for codes. The code entered on the below screen is a “no map” code in the forward direction. However, with respect to the backward mapping a different result is given. For example, the ICD-10 codes in the list 13802 are the list of codes (ICD-10 codes) which map to 707.21. This gives the user guidance in selecting the appropriate mapping.
VII. New Mappings
Embodiments of the present disclosure allow the disease classification code mapping tool to create new mappings for different business areas. Specifically, referring now to example screen shots 139 and 140 illustrated in FIGS. 139 and 140 respectively, an administrator may login, select GEMs application mode 420, and select the “Claims” business area 430, for example. The user may then go to the mapping section and enter an ICD-9 code and click on the “get equivalent ICD-10 button. A custom mapping link may be provided which produces a page 14002 which can be used to change the mapping to a different business area. Now, by going back to the home page and selecting “Care Administration”, for example, as a business area, a user can check the same mapping in the mapping section which the user recently changed. The user will be able to see the older mapping as a new mapping already saved for the different business area. Now, by selecting specific as a mode, and “Claims” as the business area, the user can check the same mapping in the mapping section that they have just changed. Consequently, the user can see the older mapping as the new mapping that is already saved for different modes.
Claims Data Analyzer for Specific Mode—Payer as well as provider claims can be uploaded on the basis of specific mode (i.e., the client/organization specific mode). This is shown in the example screen shot 141 of the upload claims screen illustrated in FIG. 141 which includes a user interface 14102 having an ICD-9 claims selection button 14104, an ICD-10 claims selection button 14106, an input claims file dialog box 14108 (optionally including a browsing feature 14110), a file description field 14112 and a “process claim file” button 14114.
Upload Section/Ranges and Get Base Mappings—This feature may be restricted to use in GEMs mode. It allows the user to upload the file which contains the ICD-9 code or ranges, and give the base mapping for individual codes as the output file. FIG. 142 is an example screen shot 142 illustrating one embodiment of such an input file 14202.
FIG. 143 is an example screen shot 143 illustrating a user interface 14302 from which a user can upload the input file. The user interface illustratively includes ICD-9 diagnosis and procedure code selection buttons 14304 and 14306 respectively, an ICD file selection field 14308 (with optional browsing button 14310), a file description field 14312 and a “submit” button 14314. A download file is illustratively identified with a link 14320 via which the file may be downloaded.
VIII. Code List Conversion and Financial Neutrality
This feature contains many functionalities including, but not limited to, the following:

- Upload specific code
- Convert code list to code range for ICD-10 codes
- Code range input to Task allocation
- Allowing access to business user to look up mappings for particular code
- Display Financial Neutrality (FN) average variance for Individual codes on Mapping Screen
- Translator to accept a list of codes and return the translations for the same
- Translator should accept the customer defined formats for translation: Benefit Migration
- Listing of Menu on role wise access and deciding proper menu names and proper access

Embodiments of the present disclosure allow a user to upload an ICD-10 code list, and will give the different ranges as an output file. FIGS. 144 and 145 are example screen shots 144 and 145 respectively of sample input and output files respectively. As shown in an example screen shot 146 illustrated in FIG. 146, a user can login as an administrator, go to the user interface 14602 and enter ICD-10 diagnosis 14604 or ICD-10 procedure 14606, select an ICD-10 code input file 146-08 (with or without an optional browsing feature 14610), and click on ICD-10 code ranges 14612 to select an ICD-10 code range file to upload.
Code Range Input to Task Allocation—This feature allows an allocator to search codes for allocation by entering an input code range. An allocator may log in, go to the task allocation section, and click on create task. Referring to the example screen shot 147 illustrated in FIG. 147, the user can select the search type forward mapping 14704 or backward mapping 1470 from a user interface 14702, and further select a search type from a pull down menu 14708 and a code range from a pull down menu 14710, and click on “search” 14712 to search codes for allocation by input code range. Illustratively, the user interface 14702 may include a “get all codes” button 14714 for retrieving all codes of the given search type.
Allowing Access to a Business User to Look Up Mappings for Particular Code—FIGS. 148 and 149 are example screen shots 148 and 149 respectively of a read only mapping and search menu for a business user with read only access. From the search menu 10202, the searched codes 10220 will be redirected to the mapping screen 14802 if clicked on any code in view only format. Specifically, a business user may login, go to the mapping section, and click on the GEMs mapping. This will show a read only mapping screen (see FIG. 149). By navigating to the search section 14902 for a diagnosis 14904 or procedure code 14906, entering a code description into the description field 14908 and clicking on the “search” button 14910, the user will be presented with display code details in a list 14920 of ICD-9 codes and a list 14930 of ICD-10 display codes. Clicking on any code will redirect the user to the mapping screen in read-only (or view) mode.
Display Financial Neutrality (FN) Average Variance for Individual Codes—This feature allows a user to calculate an average variance for individual codes. For example, referring to FIGS. 150 and 151 a user may login as an administrator, navigate to the configure section 15702, select an ICD-10 file (with or without an optional browsing feature 15106), select a file description 15108 and click on the “submit” button 15110. FIG. 150 is a screenshot 150 of a sample input file for the financial neutrality feeds.
Roles Based Security—This feature allows a user to view a particular functionality on the basis of their roles. For example, a user can login as an administrator, go to the administration section, click on create user page, and note the complete URL of this page. Consider if an allocator, for example, pasted the same URL which was copied earlier in the browser. This will redirect the user to a custom error page.
While the disclosure has been illustrated and described in detail in the drawings and foregoing description, such an illustration and description is to be considered as exemplary and not restrictive in character, it being understood that only illustrative embodiments have been shown and described and that all changes and modifications consistent with the disclosure and recited claims are desired to be protected.

Claims

What is claimed is:

1. A computerized method for translating healthcare codes from a first healthcare classification system to a second healthcare classification system, the method comprising:

receiving a first plurality of healthcare codes associated with the first healthcare classification system;

receiving a second plurality of healthcare codes associated with the second healthcare classification system; and

mapping at least one of the first plurality to at least one of the second plurality according to user-defined parameters.

2. The computerized method of claim 1, further comprising:

mapping at least one of the second plurality of healthcare codes to at least one of the first plurality of healthcare codes.

3. The computerized method of claim 1, wherein the mapping is based on a general equivalence mapping (“GEM”).

4. The computerized method of claim 1, further comprising:

classifying the mapped at least one of the first plurality of healthcare codes to at least one of the second plurality of health care codes.

5. The computerized method of claim 1, further comprising:

restricting use of at least one of first and second plurality based on a type of user.

6. The computerized method of claim 1, further comprising:

converting the mapped at least one of the first plurality of healthcare codes to at least one of the second plurality of healthcare codes.

7. The computerized method of claim 1, further comprising:

converting the mapped at least one of the first plurality of healthcare codes to at least one of the second plurality of healthcare codes in accordance.

8. The computerized method of claim 1, further comprising restricting conversion of a mapping to authorized users.

9. A system, comprising:

one or more computing devices including:

a memory having program code stored therein; and

a processor in communication with the memory for carrying out instructions in accordance with the stored program code, wherein the program code, when executed by the processor, causes the processor to perform steps comprising:

10. The system of claim 9, wherein the processor comprises the additional step of:

11. The system of claim 9, wherein the mapping is based on a general equivalence mapping (“GEM”).

12. The system of claim 9, wherein the processor performs the additional step of:

13. The system of claim 9, wherein the processor performs the additional step of:

14. The system of claim 9, wherein the processor performs the additional step of:

15. The system of claim 19, wherein the processor performs the additional step of:

16. The system of claim 9, wherein the processor performs the additional step of: comprising restricting conversion of a mapping to authorized users.

17. A computer program product comprising non-transitory computer readable medium further comprising:

code for receiving a first plurality of healthcare codes associated with the first healthcare classification system;

code for receiving a second plurality of healthcare codes associated with the second healthcare classification system; and

code for mapping at least one of the first plurality to at least one of the second plurality according to user-defined parameters.

18. The product of claim 17, wherein the mapping is based on a general equivalence mapping (“GEM”).

19. The product of claim 17, wherein the non-transitory computer readable medium comprises:

code for classifying the mapped at least one of the first plurality of healthcare codes to at least one of the second plurality of health care codes.

20. The product of claim 17, wherein the non-transitory computer readable medium comprises:

code for converting the mapped at least one of the first plurality of healthcare codes to at least one of the second plurality of healthcare codes.