Patent Publication Number: US-2022215939-A1

Title: Generation of a transaction set

Description:
CROSS-REFERENCE 
     This application is a continuation of U.S. application Ser. No. 15/393,671, filed Dec. 29, 2016 and entitled “Generation of a Transaction Set”, which is incorporated in its entirety by reference herein. 
    
    
     BACKGROUND 
     The Electronic Data Interchange Healthcare Claim Transaction set (EDI 837) is utilized to submit medical claim billing information, encounter information, or both. It can be sent from providers of services to payers, either directly or via intermediary billers and claims clearinghouses. Payers respond to the EDI 837 with an EDI Healthcare Claim Payment/Advice Transaction set (EDI 835). The EDI 835 is used to make payments, send Explanation of Benefits (EOB), send Explanation of Payment (EOP) remittance advice, and the like. The EDI 835 is used to detail payments of a claim including what charges were paid, reduced or denied; whether there was a deductible, co-insurance, co-pay, etc.; any bundling or splitting of claims or line items; how the payment was made; and the like. 
     The computer-to-computer exchange of this information calls for a specific format to be used in EDI 837 and EDI 835 generation. Because of this standardized requirement, senders and recipients of EDI 837 and EDI 835 forms must be able to process the forms quickly and efficiently. Various providers have created programs to facilitate such processing. However, testing of the runtime environment usually does not occur with respect to the 835 processing. This is because payers do not provide test cases for 835 claims and generating the 835 forms needed to test the system is a massive undertaking that is extremely time intensive and impractical. Additionally, the 835 processing systems need to be able to handle extremely large files that are sometimes too large for a given system. 
     Furthermore, the percentage of error is enormous with manual generation of 835 forms. Thus, testing of 835 processing of systems is typically not performed, which leads to live implementations of systems that have errors related to 835 processing that must be dealt with after a live implementation and, consequently, after the error has already been made with actual data. 
     SUMMARY 
     Embodiments of the present invention relate to, among other things, automated generation of 835 forms. The automated generation may be utilized for testing systems before they are implemented in a live environment. At a high level, the tool automatically generates the 835 forms and can extract information from various sources (e.g., client specific databases, user input and 837 transmissions, etc.) and assemble an 835 form in the correct format in a matter of minutes. 
     Accordingly, in one aspect, an embodiment of the present invention is directed to one or more computer storage media storing computer-useable instructions that, when executed by a computing device, cause the computing device to perform operations. The operations include detecting an indication of a database to use to generate an EDI 835 transmission (hereinafter “835 transmission”); extracting claims data from the database; detecting test data to include in the 835 transmission; and electronically generating one or more 835 transmissions corresponding to the claims data and the test data. 
     In another embodiment, an aspect is directed to a computer-implemented method for generating a user interface for an application. The method includes detecting a selection of a database to use for electronic generation of an 835 transmission; extracting, from the database, claims information from a first claim and claims information from a second claim; generating a first 835 transmission using the claims information from the first claim; generating a second 835 transmission using the claims information from the second claim; merging the first 835 transmission and the second 835 transmission; generating a merged 835 transmission including claims information for both the first 835 transmission and the second 835 transmission. 
     A further embodiment is directed to a computer system comprising: one or more processors; and one or more computer storage media storing computer-useable instructions that, when used by the one or more processors, cause the one or more processors to: detect a selection of a database to use for electronic generation of an 835 transmission; extract, from the database, claims information from a first claim and claims information from a second claim; generate a first 835 transmission using the claims information from the first claim; generate a second 835 transmission using the claims information from the second claim; merge the first 835 transmission and the second 835 transmission; generate a merged 835 transmission including claims information for both the first 835 transmission and the second 835 transmission. 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention is described in detail below with reference to the attached drawing figures, wherein: 
         FIGS. 1-15  are exemplary screenshots illustrating an 835 generation tool being used to electronically generate 835 transmissions in accordance with some implementations of the present disclosure; and 
         FIG. 16  is a block diagram of an exemplary computing environment suitable for use in implementations of the present disclosure. 
     
    
    
     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&#39;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-15  are screenshots showing electronic generation of an 835 transmission in accordance with an embodiment of the present invention. In particular, the screenshots of  FIGS. 1-15  provide an example in which an 835 transmission is generated to test one or more rules of an 835 transmission processing system. 
       FIG. 1  is an exemplary 835 transmission data set  100 . The data set  100  includes an amount remitted  101  and a provider  102 . Lines  103   a,    103   b,  and  103   c  are summed to total an amount while also taking into account lines  104   a  and  104   b.  That number is reflected at value  105 . 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 in  FIG. 1  is 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. 2  provides an exemplary interface  200  illustrating this feature. The source list  201  is provided and may be expanded via a drop down menu (as shown in menu  301  of  FIG. 3 ). Additionally, a type of transmission may be selected via options  202 ,  203 ,  204 , and  205 . A payment/denial file may be generated via option  202 . A takeback file may be generated via option  203 . A secondary payer file may be generated via option  204 . Finally, multiple files may be merged via option  205  (as discussed in further detail below). An output indicator  206  may 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. 3  provides an exemplary interface  300  for selecting the source from which to extract claims information. The drop down menu  301  may 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&#39; 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. 4  provides an exemplary interface  400  showing a payment/denial file type selection (shown as reference numeral  202  in  FIG. 1 ). A specific claim identified may be input at claim input area  402 . Alternatively, a date range for claims may be specified at range input areas  403   a  and  403   b.  The interface  400  also provides for claims information identification via a payer via payer input area  404  or a payee via payee input area  405 . Once selected, the transaction can be configured upon selection of a configuration input  406 . Appropriate configuration corresponding to the specified inputs may be provided in area  407 . 
     Upon selection of the configuration input  406 , an interface  500  provided in  FIG. 5  is presented. Here, test data, for example, may be input into the configuration dialog area  501  to configure a transmission. An expanded view is provided in  FIG. 6  at interface  600 . As shown, test data may be entered into area  601 . Provider remarks may also be input at remark area  602 . Provider adjustments may also be input at provider adjustment area  603 . 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 interface  700  of  FIG. 7 . Area  701  includes 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 interface  800  shown in  FIG. 8 . Selection of the generation button  801  initiates generation of the 835 transmission(s). 
     As shown in  FIG. 9 , the interface  900  includes the generated files the user requests. The files may be opened to view the 835 transmission (shown in interface  1000  of  FIG. 10 ). As shown in  FIG. 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. 11 and 12  illustrate interfaces  1100  and  1200  showing takeback file generation selections  1101  and secondary/payer file selections  1201 . These files utilize an existing 835 transmission to create the takeback and secondary files. 
       FIG. 13  provides an exemplary system interface  1300  showing 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 area  1301  to show individual rules within the rule set. The individual rules are provided in rules area  1302 . Selection of a rule may result in an explanation or additional detail of the rule to be provided. 
       FIG. 14  provides an additional exemplary interface  1400  showing 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 in  FIG. 6  (numeral  601 ).  FIG. 15  also provides a view  1500  of a generated transmission including the “CO45” test input  1501 . 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 numeral  205  of  FIG. 2  provides 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 to  FIG. 16  in particular, an exemplary operating environment for implementing embodiments of the present invention is shown and designated generally as computing device  1600 . Computing device  1600  is 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 device  1600  be 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 to  FIG. 16 , computing device  1600  includes bus  1610  that directly or indirectly couples the following devices: memory  1612 , one or more processors  1614 , one or more presentation components  1616 , input/output (I/O) ports  1618 , input/output components  1620 , and illustrative power supply  1622 . Bus  1610  represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks of  FIG. 16  are 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 of  FIG. 16  is 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 of  FIG. 16  and reference to “computing device.” 
     Computing device  1600  typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device  1600  and 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 device  1600 . 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. 
     Memory  1612  includes 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 device  1600  includes one or more processors that read data from various entities such as memory  1612  or I/O components  1620 . Presentation component(s)  1616  present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc. 
     I/O ports  1618  allow computing device  1600  to be logically coupled to other devices including I/O components  1620 , 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 components  1620  may 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 device  1600 . The computing device  1600  may 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 device  1600  may 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.