This is about work flow and I need guidance from a more senior programmer as I am still cutting my teeth.
A client wants to cut out more paper. I said YEAH! We are going to teach the doc to use a tablet to select from the beautiful electronic fee sheet instead of marking up a paper fee sheet and scanning and uploading. The goal here is to keep everything electronic. That was my tasking to come up with the coding and the work flow.
What I came up with was to have the doc use the Electronic fee sheet from a 10" tablet, selecting the same codes he would from the paper fee sheet. Now the problem is that the patient needs to sign the fee sheet.
What I thought of was to take the Printed Superbill and mark it up with the fees that were just entered from the electronic fee sheet by the doc. Then that could be converted to PDF and signed by the patient at check out and stored in the record never being printed.
I started on the Superbill today. I have the the Printed Superbill to import the codes from the current encounter.
printed_fee_sheet.php
//This is to place a check in the box next the code used for the encounter that day hacked by sherwin
if (empty($en_codes)){
$en_codes = array();
$res = sqlStatement("SELECT code FROM billing WHERE pid = '" . $pid . "' AND encounter = '" . $encounter . "' ");
while ($row = sqlFetchArray($res)) {
$en_codes[] = $row['code'];
}
}
//end of encounter returns
We have reworked the prior version of superbill that shows the following in separate sections :
1. Current encounter codes if it has been coded.
2. Superbill codes (original logic)
3. Top 20 Diagnostic codes for the patient if patient is known or for the entire practice
We allow physicians to click the radio buttons and enter free text. The input is saved in billing_note for biller to code correctly.
The changes also allow controlling columns compared to current logic. As our offices move to tablets, we would handle columns 2 (Tablets) and 1 for phones.
Haven’t shared code since it does support batch print from appointment report and probably some standards related stuff that we do not have bandwidth to handle.
Another word of caution - since this thing uses its own styles, we started getting consistent results only after following advice of CSS gurus and doing a reset.
As our users use different browsers, adding this code made much difference. Hopefully someone can look at it and make it part of OpenEMR standard stylesheets in the beginning or use this Google include in all pages.
Thanks for the re[y and synopsis. I would like to take a look at the code and add it to our system. It would sure save me a lot of time in developing it myself and maybe we can collaborate on getting it into the official code base. Would you mind sharing the code with us?