Model C1A3F297 Command Line Translator 1.15E-11

Model C1A3F297 Command Line Translator 1.15E-11 offers a flexible yet practical tool for developers, systems integrators, and medical billing professions to create solutions and solve problems they might encounter in their business processes relative to the scope of Electronic Data Interchange and health care. The Command Line Translator is a cost effective way to add HIPAA X12 electronic claims to an existing system. It can even be used to fix other X12 837 files that no longer meet an insurance carriers specific requirements.

Major Features:

1. THREE PART PROCESS
   • The Command Line translation process has three basic parts, an import process, a verification adjudication processing, and a compiled output process. All processes are done using the translator's database. All processes are defined out in what is called the Command File. This file can be called any eight character name followed with an extension of .CMD.
2. IMPORT PROCESS
   • The import processes available are BCU or Basic Conversion Utility, the ACU or ANSII X12 Conversion Utility, the FCU or Frame Conversion Utility, the NCU or Nested Conversion Utility used for:
3. PROCESSING VERIFICATION and ADJUDICATION
   • After an import has been completed, the processing portion of the application will begin. The Processing portion of the translation can first be defined according to a structure of either carrier or clearing. Sub options of these structures offered are batch or release. An example of this is a CARRIERBATCH. A CARRIERBATCH is a batch that has all data in it being processed because of the primary coverage of the subscribers. There are several ways to configure this type of translation. Issues such as the absence of critical data fields such as coverage name and order of coverage may play into which design factors best deal with the data quality. Another example of a processing command is CARRIERRELEASE. This method can be used for example to import in insurance claim data containing a wide variety of insurance carriers. Once imported, the claims can be processed and output grouped by carrier thus separating the claims to go to the appropriate receiver or payer.
   • Some basic data elements are critical to properly translate claims. Criticality of some data elements will vary based on things like import data quality and the nature of the business application problem that is trying to be solved. If claim data that has been imported that does not meet certain minimum requirements that claim data will be removed by the processing functions from the processing stream, and placed in a suspended status and then noted in the suspend log. The file is named SUSPEND.LOG and is in the DATA DIRECTORY.
   • In addition to the basic system verifications some critical fields like birthdays and insurance ID's can be check presence. This is configured in the C1.INI in the DATA DIRECTORY.
4. COMPILING OUTPUT
   • There are several ways to configure the system to generate output. The import process used in conjunction with the quality of the import data can dictate how to go about configuring the system for output. The Insurance Carrier and Institution databases contain information that can be pre configured with names and IDs that are needed to generate some output formats. All import configurations can be set up using these databases and the appropriate INSURANCE CONTRACT TABLE configuration settings located in the Institution Data screen. If enough data is available, the BCU and ACU can be configured to allow for full configuration on the fly. This can allow for single folder configurations with multiple providers and carriers being processed through.

WareSeeker Editor