Tracking of claim status

OpenEMR Development
#1

Hello Brady,

In OpenEMR, we generate the x12 for a particular claim and will submit that to insurance company for processing. There is no UI/report available to track the actual status of the claims to say whether x12 has been generated already/submitted to insurance, etc.
Will this be a useful feature to add in any UI to reflect the status of the claim? Please do share your views.

Thanks,
ViSolve

#2

Doesn’t this go into the log?
Another good question for super @stephenwaite

#3

hi @visolveemr @brady.miller there is the edi history module which records the generation of x12 in csv tables thanks to the work of @kevmccor

the view log from the billing manager could use the inclusion of additional details like payer name

note that none of these options will confirm that the file was actually received by the payer since the x12 file must be uploaded to them after downloading

this is where work on the 277 files could help, edih_277_html.php

#4

Hello @stephenwaite,

Thanks for your update. We suggest that we can show the claim status ( x12 generation status )
in the billing manager screen like adding one more column to display claim status, similar to view log .
The status would be like "claim generated " or "claim submitted ", etc.,

We also checked this file “edih_277_html.php” , it looks good. Is this feature under progress, because we could not find the screen in which the uploading of EDI response takes place in OpenEMR.
We did check EDI history screen , Posting screen in OpenEMR.

Kindly share your views.

Thanks
ViSolve

#5

If edi_history is to be better integrated into OpenEMR there a few basic points. 1) EDI files need to be saved into the appropriate directory, e.g. /default/edi/history/f277 ( see edih_csv_inc.php | csv_setup() and csv_parameters() ) and also keep the original file name. 2) files downloaded from the clearinghouse need to be processed so the csv tables are populated (there is a rough draft of sftp automation: test_edih_sftp_files.php) 3) a very few key data items for database listing should be picked out and saved, probably using something like edih_csv_parse.php except create database inserts instead of csv table rows. 4) Specific transactions could be displayed in a popup or dialog, but this would depend on the csv tables and file storage so the transaction can be located.

#6

@visolveemr was there a build or resolution to a claim status report? Since the EHR does not connect directly with any clearinghouse, it seems like this report would be impossible to generate.

#7

I am doing this from memory and my copy
of the source files, so please excuse mistakes. There is code to
display claim status reports (277 and 277CA) in edihistory.

  To investigate how to use edihistory in automating the edi x12

claim process, I suggest you get a fairly complete set of X12 edi
files. This could be done by an active practice office
downloading files from a clearinghouse. My recollection from
using a clearinghouse was that once the 837 claim file was
submitted there was a series of response files that followed: 837
-> 999 -> 277 -> 835.

      To automate the process, the basic

necessity is an ftp process that will download the files into a
given directory and then call the functions in edih_io.php. This
would automatically sort files and create csv tables. It should
be fairly simple to tell which 835 payment files need to be
processed by the vsolve billing process , and links could be produced to display
the claim information, similar to what you get from the looking at
the csv datables display.

  At present, these x12 files are downloaded to a folder on your

computer. Then the files are “processed” by edihistory by using
the upload file tab (possibly “New Files”).

  To track the software process, look at "edih_io.php" 

  This file is controlled by the GET and POST parameters from the

“/interface/billing/edih_view.php” [div id=“newfiles”] which are sorted in “/interface/billing/edih_main.php”

      This

process does two main things:

    1) basically sorts the files by X12 type and saves them in the

appropriate folder under “/sites/default/edi/[x12-type]” [see
edih_uploads.php]

    2) extracts data from the files for entries in the csv tables

[see edih_csv_parse.php]

  The csv tables are displayed with the "jquery datatables" program

and the data query is handled by edih_csv_data.php

  For a good example, see the function:         edih_io.php

-> edih_disp_x12trans() This function (a) gets the
identifications from GET, (b) finds the file, © calls the
functions to create the desired output, and (d) returns the
output. There are a lot of if-else clauses. The function assumes
the necessary files are stored on the system and noted in the csv
tables.

  The text rendition of the x12 file is done by edih_segments.php

and the html rendition is by the edih_[x12type]_html.php files

  I strongly suggest that the "edih_x12_file_class.php" be used for

opening and reading x12 files. Study the output to see how the
segments, transactions, and envelopes are organized. This will
make handling x12 files much more manageable and uniform in the
OpenEMR program overall. In edihistory, this class is called
through edih_csv_inc.php -> check_x12_obj($filepath, $type=’’),
which is probably too much caution. Basically do: $x12obj = new
edih_x12_file(“filepath”); and then: var_dump($x12obj);

  The reason I chose to use csv tables instead of database storage

is the transient interest of these x12 files and also speed. Once
a payment is finalized and a claim resolved, basically the files
are of no further interest. The archive process I wrote is fairly
weak and could definitely be improved, but at least there is a
complete process from upload to delete.

  I hope this is helpful.

  Kevin McCormick
2 Likes