Documentation/Readme_edihistory.html

   1 <!--
   2    README.html
   3
   4    Copyright 2012 Kevin McCormick <kevin@records>
   5
   6    This program is free software; you can redistribute it and/or modify
   7    it under the terms of the GNU General Public License as published by
   8    the Free Software Foundation; either version 2 of the License, or
   9    (at your option) any later version.
  10
  11    This program is distributed in the hope that it will be useful,
  12    but WITHOUT ANY WARRANTY; without even the implied warranty of
  13    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  14    GNU General Public License for more details.
  15
  16    You should have received a copy of the GNU General Public License
  17    along with this program; if not, write to the Free Software
  18    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
  19    MA 02110-1301, USA.
  20
  21
  22 -->
  23
  24 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  25         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  26 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  27
  28 <head>
  29         <title>EDI Claim History</title>
  30         <meta http-equiv="content-type" content="text/html;charset=utf-8" />
  31         <meta name="generator" content="Geany 0.21" />
  32 </head>
  33
  34 <body>
  35 <h3>README Claim History Project</h3>
  36 <p>
  37 This file contains notes and hints for developing and using the files and scripts in this &quot;EDI History&quot; project.
  38 </p>
  39 <p>
  40 The purpose of the project is to gain ready access to edi claim information,
  41 quickly identify submits, rejects, denials, payments, etc. and have the information
  42 in a &quot;big picture&quot; format as well as the information needed to spot problems.
  43 It is a work-in-progress, unfinished, and will hopefully be improved upon.
  44 This phase is oriented to correctly parsing the x12 files, doing basic useful
  45 things with the data, and having acceptable html output.  The next phase is improved
  46 integration with OpenEMR database information.
  47 </p>
  48 <p>
  49 Nearly all the information that is important to this project is initially found in
  50 the user's personal directories where the downloaded edi files are stored.  These are
  51 response files from payers or clearinghouses, such as claim status or ERA files.
  52 There is at present no interaction with the OpenEMR database.  Therefore, while I find this project
  53 helpful, its usefulness to others depends on the kind of edi files they have.  That said,
  54 these scripts should be able to parse 837, 835, 277, and 999 x12 files from any source.
  55 </p>
  56 <p>
  57 I use Availity, LLC as the clearinghouse for nearly all edi transfers so these scripts are
  58 definitely oriented to Availity practices.  In particular, you may want to look at your
  59 Availity EDI Preferences setup so you are getting the types of files these scripts can read.
  60 </p>
  61 <p>
  62 You should select <em>Include TA1</em> in the Availity preferences for .997 and .999 files
  63 in order for the scripts to be able to match these response files with the corresponding
  64 claims batch file you submitted.  Also, Availity provides x12 277CA files, the .277 type
  65 for unsolicited claim responses, i.e. Availity checks the claims and the payers also
  66 check the claims and return the results in a .277 file.  Importantly, file name practices
  67 of your clearinghouse or payer must be taken into account because uploaded files are
  68 categorized by file name patterns.  The patterns are found in <em>csv_record_include.php</em>
  69 in the function <em>csv_parameters()</em>.
  70 </p>
  71 <p>
  72 One Availity setting that may be important is the grouping of ERA responses.  Mine are grouped by
  73 checks from a particular payer, so my ERA files will have responses from only one payer,
  74 with perhaps more than one &quot;transaction&quot; in each file.  Also, the &quot;multipayer&quot; options
  75 help to reduce the number of Availity files one has to download.
  76 </p>
  77
  78 <h3>OpenEMR Integration</h3>
  79
  80 <p>
  81     Access control is entirely under the OpenEMR scheme and will likely require the
  82     access permissions of &quot;accounting.&quot;
  83 </p>
  84 <p>
  85     Since the information in the EDI files is likely HIPAA protected, do not use these scripts on a public server!
  86 </p>
  87
  88 <h3>File Locations:</h3>
  89
  90 <p>
  91 The installed directory tree would be:
  92 </p>
  93 <ul>
  94         <li>/openemr/interface/billing </li>
  95         <li>/openemr/library/edihistory</li>
  96         <li>/openemr/library/css</li>
  97 </ul>
  98
  99 <p>
 100 Installed files:
 101 </p>
 102 <ul>
 103     <li>/openemr/Documentation
 104         <ul>
 105             <li>Readme_edihistory.html</li>
 106         </ul>
 107     </li>
 108         <li>/openemr/interface/billing </li>
 109                 <ul>
 110                         <li>edih_view.php</li>
 111                         <li>edi_history_main.php</li>
 112
 113                 </ul>
 114         <li>/openemr/library/edihistory </li>
 115                 <ul>
 116                         <li>csv_record_include.php</li>
 117                         <li>ibr_ack_read.php </li>
 118                         <li>ibr_batch_read.php</li>
 119                         <li>ibr_code_arrays.php </li>
 120                         <li>ibr_997_read.php</li>
 121                         <li>ibr_277_read.php</li>
 122                         <li>ibr_ebr_read.php</li>
 123                         <li>ibr_era_read.php</li>
 124                         <li>ibr_status_code_arrays.php </li>
 125                         <li>ibr_uploads.php</li>
 126             <li>ibr_io.php</li>
 127             <li>ibr_271_read.php (not used as of this time)</li>
 128             <li>ibr_archive.php (not used as of this time)</li>
 129                         <li>edi_history_log.txt (created by scripts)</li>
 130         </ul>
 131         <li>/openemr/library/css</li>
 132                 <ul>
 133             <li>csv_edihistory.css</li>
 134                 </ul>
 135     <p>
 136        In addition, the project uses javascript libraries and related css already
 137        included in OpenEMR:
 138     </p>
 139         <li>/openemr/library/js <em>or</em> css</li>
 140                 <ul>
 141             <li>jquery-1.7.1.min.js</li>
 142                         <li>jquery-ui-1.8.18.custom.min.js</li>
 143                         <li>jquery.dataTables.min.js</li>
 144                         <li>jquery-ui-1.8.18.custom.css</li>
 145                 </ul>
 146
 147 </ul>
 148
 149 <p>
 150 The scripts create a temporary uploads directory: /tmp/edihist
 151 </p>
 152 <p>
 153 The <em>csv_setup()</em> function creates a file storage directory tree: </br>
 154 &nbsp;&nbsp; openemr/sites/default/edi/history </br>
 155 with subdirectories: ack  csv  dpr ebr  era  f277  f997  ibr  text
 156 </p>
 157 <p>
 158 and these csv files under: /openemr/sites/[site]/edi/history/csv</br>
 159 &nbsp;&nbsp; claims_277.csv  claims_ebr.csv  claims_ibr.csv  files_277.csv  files_ebr.csv       files_ibr.csv</br>
 160 &nbsp;&nbsp; claims_997.csv  claims_era.csv  claims_dpr.csv  files_997.csv  files_era.csv</br>
 161 </p>
 162 <p>
 163 The path to these files set by <em>csv_edih_basedir()</em> based upon the OpenEMR directory paths.
 164 </p>
 165 <p>
 166 Note:  I suggest the following edit to the OpenEMR <em>billing_process.php</em> script:
 167 <br />
 168 &nbsp;  In the file openemr/interface/billing/billing_process.php
 169 &nbsp;  in &quot;function append_claim(&amp;$segs)&quot;  near line 82  (after the &quot;if (elems[0] == 'ST') { }&quot; block)
 170 </p>
 171 <pre><code>
 172     // add this mod
 173     if ($elems[0] == 'BHT') {
 174        // give each claim a unique BHT number, used in x12 277 files : isa-control-num and st-num are concatenated
 175        //
 176        $bat_content .= str_replace("*0123*", sprintf("*%s%04d*", $bat_icn, $bat_stcount), $seg) . "~";
 177        continue;
 178     }
 179 </code></pre>
 180
 181 <h3>Usage</h3>
 182 <p>
 183 Once installed correctly, you begin usage by uploading your edi response files.
 184 </p>
 185 <p>
 186 On the first usage the setup function will be activated and the log file will be created.
 187 It will write the directory paths and create the csv files.  If this fails, the script will
 188 terminate and nothing more will happen.  Failure is probably caused by file permissions problems.
 189 </p>
 190 <p>
 191 The EDI History project features a tab format and the &quot;New Files&quot; tab is where we begin.
 192 You can select one or more files or upload a zip archive.  The batch files are saved in the
 193 <em>/openemr/sites/[site]/edi</em> directory by OpenEMR when they are created, so you should not need to upload
 194 batch files.  Note the web server configuration will likely have a maximum for the number of
 195 files and the size of the upload.  The steps for uploading your response files are:
 196 <ol>
 197     <li>Click on the &quot;EDI History&quot; entry under Fees in the left_nav menu and select the &quot;New Files&quot; tab</li>
 198     <li>Click the <em>Browse</em> button and select files (response files you have downloaded)</li>
 199     <li>Click the <em>Submit</em> button (the selected files are sorted and copied to their respective directories).</li>
 200     <li>Repeat 2 and 3 as needed</li>
 201     <li>Click the <em>Process</em> button (information from new files is extracted to the csv tables)</li>
 202 </ol>
 203 </p>
 204 <p>
 205 If you have batch files already stored in your <em>/sites/[site]/edi</em> directory, there may be a large amount of output
 206 listing the batch files.  You can uncheck &quot;HTML Output?&quot; to avoid this.  Also, if you wish to upload a
 207 large quantity of existing files, you can put then in a zip archive (no subdirectories) and upload the zip file.
 208 </p>
 209 <p>
 210 In ordinary usage, the &quot;New Files&quot; tab is intended to handle uploads and give a summary of
 211 the information in your new response files.  You will see output for each type of file, giving some particulars and
 212 listing claim information when problems are indicated.  Links allow more detailed views.
 213 </p>
 214 <p>
 215 Each file is checked when uploaded and files that do not meet the criteria will not be accepted. &nbsp; : ( &nbsp;
 216 If an uploaded file is already present, it will be discarded.  So, you can upload duplicates without
 217 worrying about whether it is already there.  Once a file is uploaded and stored, it is not overwritten
 218 or modified in any way, though the files are read to extract information or the contents are formatted for viewing.
 219 </p>
 220 <p>
 221 The &quot;CSV Tables&quot; tab is useful after the EDI History page is reloaded in your browser, by clicking the left_nav entry,
 222 since it checks the csv table files and adds them to the list of available tables if they have the minimum size. The
 223 &quot;CSV Tables&quot; tab allows you to locate particular claims or files with the sort and search features of the
 224 <a target="_blank" href="http://datatables.net/">DataTables</a> javascript plugin.
 225 </p>
 226 <p>
 227 The &quot;ERA Files&quot; tab is intended to allow you to see an RA style output of ERA files in your personal
 228 directory, as well as to see RA style output for a patient ID, encounter number, or trace (check) number from
 229 ERA files that have been uploaded.
 230 </p>
 231 <p>
 232 The &quot;X12 Text&quot; tab allows you to see the contents of a response file in your personal directory.
 233 The &quot;Notes&quot; tab allows you to view the log file and have a plain text notes file.
 234 </p>
 235 <p>
 236 The EDI methods and files are cryptic and mysterious.  The formats are definitely not what I would call
 237 user-friendly.  The contents and meaning of the various files, loops, and segments may be better understood
 238 with serious research.  There are so called &quot;Companion Documents&quot; published by some insurance companies
 239 and possibly by your clearinghouse.  Search for &quot;X12 835 837 277 999 Companion Document&quot; and see if you find
 240 anything useful.  Another good source is the CMS/Medicare side-by-side comparisons, put out to aid the transition from the 4010
 241 to the 5010 standard, e.g. <a target="_blank" href="http://www.cms.gov/Medicare/Billing/ElectronicBillingEDITrans/downloads/ProfessionalClaim4010A1to5010.pdf">ProfessionalClaim4010A1to5010.pdf</a>.
 242 </p>
 243 <p>
 244 Hopefully, the EDI History project will help you solve billing problems and have a better grasp of your
 245 billing and collection process.  Note however, no accounting functions are included in the scripts, so
 246 whatever accounting process you use remain necessary.  These scripts are basically for information only.
 247 </p>
 248 <p>
 249 There is the thought that there may eventually be so many response files that older
 250 ones are no longer wanted.  There is a draft script for archiving files and table contents into a
 251 zip file, but it is not well tested and there is no button to run it.
 252 </p>
 253 <p>
 254 Although there is a script for reading x12 271 files (eligibility), it is only a draft and does not
 255 do anything.  Since OpenEMR does not have the present ability to submit eligibility requests, I
 256 have no 271 response files to decipher so as to finish the script.
 257 </p>
 258 </body>
 259
 260 </html>