3.2 Test & Documentation

ideaman911 wrote on Tuesday, January 12, 2010:

Tony;  Per your suggestion, this is a new thread.

All;  I tried a full Windows install with the latest (1.7.3) Xampp, then upgraded my 3.1.0 data.  It went fine, although I was nervous about the vague description of securing the “apache configuration file”, which I still do not understand, so no relative newbie will be happy with that description.

Some problems still exist with the apostrophe (’) character.  Since Brady fixed it in 3.1 I have not found any fields which will not tolerate them.  But try to find all with an apostrophe in the LName with a single apostrophe in the Find box and you will get nothing.  That will also be true for every search in the main left frame except the All selection.  That will ONLY find when an apostrophe is in the common text of a field which is unrestricted.  I have not tested every permutation, but selecting the Filter fields does not help, except to find those which the All finds by default - it does NOT find any with apostrophe in LName.

A series of fails occur in Demographics for SSN mismatch.  They really need to ignore blanks completely, like same for non-self, or at least allow the user to accept them as blank if they are.  Right now it simply prevents progress, causing loss of all the other demographic data changes.  Not good.

Brady;  Thanks for the changes in the Billing Report, but the class.ezpdf.php file still needs the margins set from 30 to 5 to work properly in Windows.  Have you actually heard from anyone who says the 5 does NOT work in Linux, etc?  It is VERY hard to see the difference UNLESS you HAVE TO have text match physical space & locations, as the CMS1500 must.  No simple page print which ises the same class.ezpdf.php would know the difference.

Rod, Tony, et al;  The instructions say 3.1, but the screenshots are 3.01, and we are at 3.2.  So the instructions, and I would urge the screenshots, should be made to reflect the default, which is now TREE view.  If someone wants to make the original editable accessible by me, I will be happy to make the changes.  Let’s make it look like it really does, OK?  And let’s make the instructions adequate for a newbie to do it without need for the forums.  So that implies especially a specific chapter on changing the globals.php, since there are so many things which users might wish to change, but likely not until after they actually use it OpenEMR a bit.  Newbies are generally neurotic about such stuff, which I think is good.  And as long as a specific instruction HowTo on the globals.php exists, the FIRST instruction should be to make the display what they are familiar with - ie changing between traditional, radio & tree views.  No newbie will care, but those who used versions prior to 3.1 will likely not be familiar with the tree view, and we should make it easy for them as well.

Just my two cents.  Yours?

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com
http://www.holzerent.com  or  http://www.EMRofCNY.com

Speaking of which, I see how to create a Layout-Based Form (LBF), but I see now way to access it, nor instructions.  I would REALLY like to make certain that is fully described to show users how to create, use, and then access later such forms.  Rod;  I think you authored this - do you have some instructions?  I’ll be happy to flesh it out.

Lastly; while I cannot possibly say I did exhaustive testing, I tried to reflect known issues above.  I have NO ability to test multi-language, especially non US character sets.  Pimm et al; could you post on that testing?  Thanks.  And nice job all.

ideaman911 wrote on Tuesday, January 12, 2010:

Sorry - “ises” should read “uses”.  And how the signature got ahead of the last two paragraphs, who knows.  Sorry.

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com
http://www.holzerent.com   or  http://www.EMRofCNY.com

sunsetsystems wrote on Tuesday, January 12, 2010:

Hi Joe, there is some info about layout-based visit forms here:

https://sourceforge.net/projects/openemr/forums/forum/202506/topic/3344495

As for using them, just go to an encounter and pick the one you created from a drop-list the same way you select other forms.

Rod
www.sunsetsystems.com

bradymiller wrote on Wednesday, January 13, 2010:

Joe,

thanks for the test. regarding ezpdf.php, so far have one linux user who says 5 is fine and none that say it isn’t. conclusion, i’ll change it to 5.

also a howto page by Pimm in wiki for the layout-based form stuff here:
http://www.openmedsoftware.org/wiki/LBV_Forms

also, if you can, log the searching apostrophe bug in the tracker to remind us when we have some free time

-brady

blankev wrote on Wednesday, January 13, 2010:

I found an apostrophe issue in 3.3 on the Server of the GUI developer, but could not recreate it in Demos V3.1 nor in V3.2.
(I think it was in the new GUI interface, but since this was another sever I did not register the exact location)

Input something like I don’t know was after saving changed in " I don 't know " There was no possibility to get rid of the backslash, only solution was " I do not know " without the apostrophe.

Other translation issues in Dutch seem to be only in a few spots. Some words are not possible to translate, of the English words show no difference for the same word.

See the example of  “To” and “To”

I send this letter " to : " Doctor XXXX
I want the report s " from "  this date: yyyy/mmm/dd  " To " that date:  " yyy/mm/dd "

But I will keep you informed if I find some other issues.

Pimm

bradymiller wrote on Wednesday, January 13, 2010:

Joe,

Just comitted margin changes to openemr/library/classes/class.ezpdf.php to development tip and 3.2 branch. It will show up in demo and in the .zip package tomorrow. Let me know how it works.

thanks,
brady

ideaman911 wrote on Wednesday, January 13, 2010:

Brady;

As I noted, when I changed that, as long as my printer driver itself would take the image 100%, every printer I own works fine for CMS 1500 forms with the 5 vs 30 in the EZPDF, and I have never seen any downside from that elsewhere.  Thanks.

I will post the bug tracker with my findings for the apostrophe.  I had already submitted more than a month ago on the blank SSN issue, but it somehow got lost?  Do I resubmit on that?  3.2 looks great otherwise once we get the instructions to match it.

Tony;  Do I see that you have someone doing them?  How about sending me directly a copy of the text as a DOC, and I will rapidly return a marked-up, and include a bunch of screenshots I would suggest re those markups from the 3.2?  I will not be revising everything by any means, especially since you seem to have someone doing that.  Just the stuff I think is either too inadequately covered or confusing.  MY objective will be to have the Fee Sheet instructions, the PLX file usage (especially for Windows), and the new Layout Based Forms incorporated.  I will also mention the PDF print sizing for the CMS1500 forms.  Your thoughts?

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com
http://www.holzerent.com  or  http://www.EMRofCNY.com

tmccormi wrote on Thursday, January 14, 2010:

Joe,
   Yes, I have my tech writer starting that process this week.   I think trying to merge your changes/markup with hers will be an issue, so just sent the notes and artifacts you what to contribute to me separately and then she’ll pull it together and produce the html side as well.  You contributions will be appreciated and used.

Tony

tony@mi-squared.com
  

tmccormi wrote on Friday, January 29, 2010:

Sara is well on the way to having an updated 3.2 doc ready.   We think that the User’s Guide, which is really and introduction to basic setup and use, should stay that way and an addendum should be created to talk about the more complex configuration, setup things that Joe has written about.   It’s disruptive to the start up process to embed too much data, we think.

Comments?

-Tony

ideaman911 wrote on Saturday, January 30, 2010:

Tony;

I am of two minds - Agreed completely that TMI is as useless as too little.  But if we don’t include the info so it is at least available in the distribution, we prevent remote users from knowing even if we build in a large number of links.

So I guess my reply is a conditional - how about we at least put in the links to the Wiki explanations for more complex stuff, and make note that will be the case right at the beginning of the instructions so users have the ability to at least know they are available and can plan to look?

The Search functions in OpenEMR vary somewhat depending on where the search is performed, and the search choices vary as well.  So each is covered separately below.

Left Frame “Find: by:” Search
The “Find: by:” box at the lower left allows you to place in the box as few as a single character on which to perform the search of the “patient_data” database field(s) chosen beneath the box with any of the six choices;  “Name” will only check the Last Name field (lname in the database), “SSN” and “DOB” should be obvious, “Any” will look for the text match in all the fields within the database, so will be very slow if you have a large number of records, “ID” looks in the “pubpid” field, which can be different from the “pid” field which is usually assigned automatically when a new patient is created.  The “pid” must have only one, whereas the “pubpid” can have multiple matches.  Lastly, “Filter” allows you to select the fields you will include in the search by using the check box for each, so like “Any” can be slower depending on the number chosen. 

Note that all patients which match the selected criteria will be listed alphabetically according to “lname”, and that list will require use of the “<<” and “>>” at top right of the list to scroll to the next grouping which are limited to 100 in the distribution to save post times, unless you change that setting in the …/interface/globals.php file.  Also note that non-standard characters like an apostrophe can have unusual results, which are being investigated as of this writing.  So putting an apostrophe in the box will find no matches in “Name”, and has not been tested for in the “ID”, “DOB” and “SSN” where they should never exist anyway, but will find them in the “lname” field if either “Filter” or “Any” is chosen.  That may be fixed before you read this.

Starting from version 3.3, “Filter” search will actually display the “Demographics”, and will change each field you select to yellow (for those who are colorblind, this can be changed to another color which works for you in the globals.php settings) from the original white, as that is believed to be easier to manage than the checkbox list in earlier versions.  And versions prior to 3.1 did not include the “Any” nor “Filter” choices.

Once the list is shown, you simply click on the desired patient and their demographics will display.  If you leave the “Find: by:” box blank, ALL patients will be listed alphabetically according to last name.

Calendar Search
As you can see, selecting to search within the calendar looks completely different, and acts that way also.  You must set the search criteria in each of the fields.  Note that the “Keywords” allows you to type words separated by a space, while the drop-down “AND “ or “OR” selection will effectively place that between the words when searching.  That search will be made on the records within the calendar, which can result in some funny “finds”.  For example, entering an apostrophe and a “c” separated by a space with the “OR” selection will find names which contain neither, but if the provider or the visit category include them, will also be found and listed.  Note that your choices in the drop-downs are limited to ALL or a single one.  The display order is the appointment time, first to last of the group, and clicking will bring you to the “Edit Event” window for it.

Calendar Add Search
The Add Search operates differently again.  Clicking the Add button brings the “Edit Event” window, where the only search function can be on the “Patient:” field.  Clicking there brings another window, where your choices at this writing are limited to only one of the fields listed.  Type the character(s) to match.  “Name” is actually only last name, and it also has the search problem with an apostrophe.  Currently being considered is making the choices equal to those in the Left Frame.  This may have changed by the time you read this.

Superbill (Admin – Services in Tree View) Search
This is one of the most severely limited searches in OpenEMR.  It ONLY allows entry of the CODE to match and its type, and not even its description, so you can at best get the short list of similar codes.  When the Superbill screen first comes up, it is the same result as you would get by selecting “ALL” and typing nothing in the search box, followed by pressing the Search button.  You can select to “Delete” or to “Edit” one from the list, or create a new one using the fields at the top.  This listing is the group which will be available in the next search section below.  These lists can also be populated using the PLX files described elsewhere.

Encounter – Add Issue Search
The only field which results in a search is “Diagnosis:” which looks at the Superbill list, but looks at the description, giving the result as only a code.  The default is ICD9, but you can type the other kinds in the left box as CPT4 and HCPCS.  Note that this is surprisingly NOT a dropdown, so mis-typing is prone to errors.  And many users have ICD10 codes in place, whereas the “ICD9” finds them because it looks for a code match.  Typing into the search field “depr” for example, will find all codes of the type which have the string “…depr…” anywhere within them.  Selecting one will bring to the “Add Issue – Diagnosis:” line its code type a colon and its code (eg. “ICD9:296.33”).  Smartest use for this is to use the Problem blocks at the top, which are filled using the …/custom/clickoptions.txt file as described in the Fee Sheet Instructions, also found in the Wiki, to populate the Title: field, which carries over to the Issues List with its date added for all subsequent encounters.  You can see why the advantages to the combined code and description, vs the normally displayed code only.

Patient – Management – Add/New (New Pt in Radio Buttons) Search
Similar to the “Find: by:” process described above, but limited to the fields in which you enter data (these will change color to augment your awareness from Ver 3.3), this will list all those whose fields match all the data entered after you press the Search button, except they still cannot find a special character like apostrophe unless that has been fixed before you read this.  Fields left blank or unchanged from initial display will not be used in the search.  The general purpose for this is to allow users to prevent duplicate patient record creation by first checking to see if the patient exists already, before adding one.

Like all searches, it is best to enter only a few (four is best usually) characters which occur in a name, etc.  That will generally provide for the nearest matches.  You should think about human errors, though.  Someone walking in calling themself “Wallace” might be incorrectly entered as any of  “Wollise, Wallise, Wolice, Walice, etc.”.  And a name like “Utah” could start with U, Eu, You, etc.  So it is a good idea for an administrator to periodically do a critical review of data to try to minimize problems.  If they are found, you may have to move data between patients, before you delete any existing duplicate.  And note that deletion does not remove records of that PID from the system.

Other OpenEMR Searches
There can be other searches which will generally follow one of the rules sets above.  But some may still have unique behaviors, like displaying “\’” in a field after you entered an apostrophe.  Generally, the latest version or patch update will correct those, but if you find a new one, please bring it to our attention in the forums at

  https://sourceforge.net/tracker/?group_id=60081&atid=493001 

Good Luck with your searches in OpenEMR.  And if you need specialty search setups (or other special functions) for your practice, they can be provided for a fee by one of the commercial vendors listed at

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com  or  joe.im0602x@gmail.com
http://www.holzerent.com  or  http://www.EMRofCNY.com

ideaman911 wrote on Saturday, January 30, 2010:

All;

SORRY about that.  The size of the entry window precludes seeing when you inadvertently copy a bunch of text you did not intend.

Any chance the “Add a Reply” box could be larger than five lines?

Joe Holzer    Idea Man    315-622-9241     im@holzerent.com  or  joe.im0602x@gmail.com
http://www.holzerent.com  or  http://www.EMRofCNY.com

dlee5400 wrote on Tuesday, February 02, 2010:

I have been reviewing 3.2 and I have a question regarding the “Visit Forms” on the tree menu. Are these menu items tied to default forms or will these have a method to customize for each doctor’s need?

sunsetsystems wrote on Tuesday, February 02, 2010:

The forms in the tree menu are just a duplication of those available from the drop-downs when you open an encounter.  There are a few different ways to add your own custom forms, and there are also more pre-made forms that you can copy from contrib/forms/ to interface/forms/.  See the wiki for more about encounter forms.

Rod
www.sunsetsystems.com

bradymiller wrote on Tuesday, February 02, 2010:

hey,
Here’s a wiki link to a new feature in version 3.2 to create custom forms:
http://www.openmedsoftware.org/wiki/LBV_Forms
-brady

dlee5400 wrote on Saturday, February 06, 2010:

Has anyone created a sample database to import?

dlee5400 wrote on Saturday, February 06, 2010:

Is there a specific date targeted for the 3.2 release ?

sraj49 wrote on Saturday, February 06, 2010:

While on this, I habe been testing 3.2.0 at various stages and I find the following in the Calendar area. When I click on Calendar the default date appears. Next when I click on a provider nothing shows up but after slecting the provider I cliak on the default date ( which is today) the appointments appear. There seems to be some bug. The version I tried month ago did not have this problem.

I have another issue, may be this should ne in the feature request area. In billing when an encounter is created the provider slects the issue and the Diagnostic code is selected . In the next stage when you go to the fee sheet again we have to select the same Diagnostic code. Can thie be auto filled in the fee sheet. This will save a lot of time.

Thanks

Raj

bradymiller wrote on Saturday, February 06, 2010:

dlee5400,
The 3.2 offcial demo will have a sample database that you can always scrape sample data from (this usually follows about a month after the official release, since the demo iss based on the OpenEMR Appliance Package.

Let’s make target date 2/16/2009

-brady

bradymiller wrote on Saturday, February 06, 2010:

sraj49,
restart web browser and remove all cookies from web browser. still have bug?
-brady

sraj49 wrote on Saturday, February 06, 2010:

After removing all the cookies it works fine. But when I restart the smae issue starts again. Thanks brady, it seems to be the cookie issue.