Patent ID: 12237077

DETAILED DESCRIPTION

The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

Embodiments of the present invention provide electronic generation of 835 transmissions utilizing generated claims. An 835 transmission generator of the present disclosure utilizes generated claims found in one or more databases to electronically generate 835 transmissions for system testing before implementation. The one or more databases may be separate from the processor including the 835 transmission generator. The one or more databases may be associated with an entity different than the entity associated with the 835 transmission generator.

The 835 transmission generator can evaluate the one or more databases to identify what claims have been generated. The information from the generated claims (“claims information”) may be used to populate 835 transmissions. The types of data extracted can include claims tables and master files that include payer information, payer name, patient name, services rendered with charges, expected reimbursements, dates of service, providers, etc.

The 835 transmissions may be supplemented with test data used, for example, to test rules that pertain to 835 transmissions. For example, test data that specifically tests rules written for the system may be input into the 835 transmissions to test specific rules to make sure they are performing correctly. Different rules may be desired for 835 transmissions from different entities. Thus, the tool provides a way to test several different rules applied to 835 transmissions such that 835 transmissions from several different entities are processed correctly.

Typically, users do not test systems for 835 transmission processing performance prior to live implementation of the system simply because the generation of 835 transmissions is too time consuming and test cases for 835 claims is not something provided by payers. However, once live implementation occurs without testing, problems may be detected that could have been caught during testing. For example, a transmission did not transfer the residual balance to the next coordinating party, but the entity of the system wanted it to transfer or vice versa. Transmissions may be lost altogether or rejected. Once processed with an error or rejected, the processing is done. Rules may be changed to handle the transmissions going forward, but it is not easy to clean up the already-made mess. For instance, a rejected transmission is rejected and won't be reprocessed. Thus, it could take weeks to correct the error in processing since it will have to be corrected via manual efforts (e.g., telephone calls to other entities such as insurance companies to correct the error). The tool solves these problems by generating hundreds of remittances (or even more) that mirror what will come back from payers in little time at all.

Additionally, 835 files have been increasing in size to sizes too large to handle by 835 processing systems. The 835 transmission generator of the present invention can create test files that are extremely large in size to test the size capabilities of the system. This provides insight into what the system can handle and also in potential areas to increase scalability in order to increase the processing power of the system.

By way of example to illustrate,FIGS.1-15are screenshots showing electronic generation of an 835 transmission in accordance with an embodiment of the present invention. In particular, the screenshots ofFIGS.1-15provide an example in which an 835 transmission is generated to test one or more rules of an 835 transmission processing system.

FIG.1is an exemplary 835 transmission data set100. The data set100includes an amount remitted101and a provider102. Lines103a,103b,and103care summed to total an amount while also taking into account lines104aand104b.That number is reflected at value105. Additional information may be included in 835 transmissions including, but not limited to, services rendered and codes corresponding thereto, remittance response codes, payer indicator, payee indicator, patient name, charge information, date of service, and the like. If generated by hand, the 835 transmission would need to be replicated exactly as it appears—every asterisk, every space, every single character shown inFIG.1is necessary for successful processing of an 835 transmission of the represented generated claim. Furthermore, there are hundreds and hundreds of codes to choose from in the generation of the forms (e.g., any codes that are within the lists maintained by the National Uniform Claim Committee listing and the Centers for Medicare and Medicaid Services). This is a massive undertaking that is not easily accomplished.

The 835 transmission generator of the present disclosure can extract the data from all necessary sources and format it such that it complies with the 835 transmission format standards. Thus, the 835 transmission generator can electronically generate the 835 transmission, including data from one or more sources, format the data, and create a unique header for each generated 835 transmission.

Initially, a database, or any other source, may be selected from which to extract claims information.FIG.2provides an exemplary interface200illustrating this feature. The source list201is provided and may be expanded via a drop down menu (as shown in menu301ofFIG.3). Additionally, a type of transmission may be selected via options202,203,204, and205. A payment/denial file may be generated via option202. A takeback file may be generated via option203. A secondary payer file may be generated via option204. Finally, multiple files may be merged via option205(as discussed in further detail below). An output indicator206may also be provided to designate where the output should be stored. For instance, a user may want to generate a plurality of 835 transmissions to utilize for testing a system and may wish to keep each generated 835 transmission saved in the same location.

As previously mentioned, the database selected may be associated with the same or a different entity than the entity associated with the 835 transmission generator. The database may include an electronic medical record database comprising a plurality of electronic medical records of patients. The database may include claims that have already been submitted for reimbursement. By using actual claims data, the generated 835 transmission for testing will be more reliable.

FIG.3provides an exemplary interface300for selecting the source from which to extract claims information. The drop down menu301may be expanded and any source therein may be selected. Exemplary sources may include data stores including claims information. An entity testing their system may, for instance, configure their data store to link with the 835 transmission generator. Other entities' data stores may also be linked such as payers, for instance. Alternatively, the 835 transmission generator may use an actual claim file to create the 835 transmission.

FIG.4provides an exemplary interface400showing a payment/denial file type selection (shown as reference numeral202inFIG.1). A specific claim identified may be input at claim input area402. Alternatively, a date range for claims may be specified at range input areas403aand403b.The interface400also provides for claims information identification via a payer via payer input area404or a payee via payee input area405. Once selected, the transaction can be configured upon selection of a configuration input406. Appropriate configuration corresponding to the specified inputs may be provided in area407.

Upon selection of the configuration input406, an interface500provided inFIG.5is presented. Here, test data, for example, may be input into the configuration dialog area501to configure a transmission. An expanded view is provided inFIG.6at interface600. As shown, test data may be entered into area601. Provider remarks may also be input at remark area602. Provider adjustments may also be input at provider adjustment area603. Unlike previous solutions, the present tool allows for inclusion of provider remarks and provider adjustments in the 835 transmission.

The inputs provided are included in an electronically generated 835 transmission. A user may, for instance, input specific test data here to trigger an existing rule to make sure the rule is performing properly. Once configured, the rules are generated as shown in interface700ofFIG.7. Area701includes configurations that will be utilized to populate 835 transmissions. Multiple configurations can be created to populate variations within one 835 transmission.

As shown, multiple configurations may be generated to allow for testing of different scenarios. Providers do not adjudicate everything the same so many different files may be desired to test many situations. Additionally, providers do not adjudicate a similar file from different entities the same. For instance, a provider may adjudicate a file from entity A one way but adjudicate a file from entity B differently. Rules can be built into the 835 transmission processing system to handle these different scenarios and the 835 transmission generator can test each one of them. Once the desired rules are populated, selection of the OK button navigates a user to a generation interface800shown inFIG.8. Selection of the generation button801initiates generation of the 835 transmission(s).

As shown inFIG.9, the interface900includes the generated files the user requests. The files may be opened to view the 835 transmission (shown in interface1000ofFIG.10). As shown inFIG.10, the generated transmissions include the info that was input. The tool allows you to include remark codes and provider adjustment segments and uses the database to fill in the claims information (provider information, claim number, insurance policy number, medical record number, dates of service, allowed amounts, etc.).

FIGS.11and12illustrate interfaces1100and1200showing takeback file generation selections1101and secondary/payer file selections1201. These files utilize an existing 835 transmission to create the takeback and secondary files.

FIG.13provides an exemplary system interface1300showing one or more rule sets that may be written into the 835 processing system. These are, for example, some of the rules a user would like to test. Rule sets may be selected from a rule sets area1301to show individual rules within the rule set. The individual rules are provided in rules area1302. Selection of a rule may result in an explanation or additional detail of the rule to be provided.

FIG.14provides an additional exemplary interface1400showing specific rules to test. Note that one of the rules has an “Adj. Group Code” of “CO” and a reason code of “45”. “CO 45” was input into the 835 transmission to test this rule as shown inFIG.6(numeral601).FIG.15also provides a view1500of a generated transmission including the “CO45” test input1501. Thus, a user can expect that the generated transmission including the “CO45” test input will be handled a certain way pursuant to the rules of the system. If so, that rule has been successfully testing for implementation. If not, it will be easy to detect there is a problem to address. In this instance, the tool provides for iterative processing capabilities to re-process the 835 transmission until the problem is addressed.

Additionally, as previously mentioned, the tool has the ability to merge files to test multiple data sets at once. Selection of the button indicated at numeral205ofFIG.2provides a merge option. Multiple files may be merged together and the files may be of different types. For instance, a payment and secondary payment file type can be merged into one file. Additionally, payment files and takeback files may also be merged together. Any types of files can be merged into a single file. Every file has a unique header unique to that file and there can only be one set of headers in an 835 transmission. Thus, the 835 transmission generator extracts header information from each of the files to be merged and translates the information into a merged header that represents each of the merged files.

Once files are merged, a total number of lines and check amount is recalculated by the tool. For example, each of the files merged included a total number of lines of that file but when it was combined with other files, the merged transmission has a different number of lines than each of the files combined therein. Thus, the total number of lines is recalculated and included in the transmission data. A similar process is followed for check amount where payments amounts from each file are combined and included in the transmission data.

Having described implementations of the present disclosure, an exemplary operating environment in which embodiments of the present invention may be implemented is described below in order to provide a general context for various aspects of the present disclosure. Referring toFIG.16in particular, an exemplary operating environment for implementing embodiments of the present invention is shown and designated generally as computing device1600. Computing device1600is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing device1600be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

The invention may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a personal data assistant or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. The invention may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, more specialty computing devices, etc. The invention may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.

With reference toFIG.16, computing device1600includes bus1610that directly or indirectly couples the following devices: memory1612, one or more processors1614, one or more presentation components1616, input/output (I/O) ports1618, input/output components1620, and illustrative power supply1622. Bus1610represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks ofFIG.16are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component. Also, processors have memory. The inventors recognize that such is the nature of the art, and reiterate that the diagram ofFIG.16is merely illustrative of an exemplary computing device that can be used in connection with one or more embodiments of the present invention. Distinction is not made between such categories as “workstation,” “server,” “laptop,” “hand-held device,” etc., as all are contemplated within the scope ofFIG.16and reference to “computing device.”

Computing device1600typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device1600and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device1600. Computer storage media does not comprise signals per se. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

Memory1612includes computer storage media in the form of volatile and/or nonvolatile memory. The memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical-disc drives, etc. Computing device1600includes one or more processors that read data from various entities such as memory1612or I/O components1620. Presentation component(s)1616present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.

I/O ports1618allow computing device1600to be logically coupled to other devices including I/O components1620, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc. The I/O components1620may provide a natural user interface (NUI) that processes air gestures, voice, or other physiological inputs generated by a user. In some instance, inputs may be transmitted to an appropriate network element for further processing. A NUI may implement any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye-tracking, and touch recognition associated with displays on the computing device1600. The computing device1600may be equipped with depth cameras, such as, stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations of these for gesture detection and recognition. Additionally, the computing device1600may be equipped with accelerometers or gyroscopes that enable detection of motion.

As described above, implementations of the present disclosure relate to a design tool that facilitates generating user interface code for applications. The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present invention pertains without departing from its scope.

From the foregoing, it will be seen that this invention is one well adapted to attain all the ends and objects set forth above, together with other advantages which are obvious and inherent to the system and method. It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by and is within the scope of the claims.