All forms, except six, were removed from the OpenEMR for Mandrake 2.7.1. Form information affects many areas. Some of the areas include:
1.Date of the encounter;
2.Reports within patient information;
3.Superbill Report;
4.Display in the main encounter screen;
Only the six forms included in the OpenEMR for Mandrake 2.7.1 will properly display in the above four areas. None of the excluded forms work with the Superbill Report. Most of the forms will not accept different encounter dates. Some of the patient reports will not display correctly.
For this reason, all non-conforming forms were removed in the creation of OpenEMR 2.7.1 for Mandrake. We thoroughly tested these forms, reports and billing functionality and made all of the required changes for proper performance of these forms.
Some discussion has begun concerning multiple patient encounters open within different tabs of the same browser. This feature is not currently available with OpenEMR. I am not sure if anyone is undertaking this project, but if this project should be completed, this change would also require revision of the existing forms.
Prior to removing the old forms, we evaluated the time to revise and test the existing non-conforming old forms to meet the new standard. We found that in many cases it would be quicker to create a new form than to edit the old form to meet the reporting requirements. For that reason non-conforming, non-working forms were removed.
So, what is the criteria that a form must meet in order for it to be used in OpenEMR is my question. I created a form using the formwiz and it seems to work like the others (it saves the data, shows the data in the encounter-summary area, displays data in the report). I’m not sure what the superbill part is. What do you mean by “accept different encounter dates”?
I need to create a bunch of forms and would like to do it correctly. As far as I can tell, mine work the same as those included in the 2.7.1 version, but not really sure.
Build a thorough test plan of the complete application, test against that plan and create patches based on variances.
When adding a form, as with any additional feature in OpenEMR, the information in that area touches many other areas. Thorough testing of the forms is one of the best means to insure the quality of your work.
When creating forms some areas to evaluate are:
1. Change of Date of Service. If services are provided on a different date, is that date saved as part of the form. For example, if today is 2/9 and services were provided on 2/7, and 2/7 is entered as the the date of the encounter, is the information preserved? Does it display in the reports with a date of 2/9 or 2/7;
2. When I save the form with a prior date, exit the encounter and return to the encounter the next day to enter more information, what is the date that is displayed for the encounter and on the information entered today for the prior encounter;
3. When I generate X12 claims, does the correct date appear for services;
4. Comparative Information. Is the form designed to show comparative information? Will this form show a history of past encounters similar to the Vitals form? If so, does the information display correctly? Are the dates correct? Is the information properly formatted for presentation?
5. Billing Within the Form. Is the form designed with billing features embedded within the form? If I enter information in the form will coding automatically be added as a result of the text entries? Does that information carry properly for billing;
6. Reporting. Within a patient’s information is a section for Reports. Will the information from the encounter display in the report? Is that format usable for a reader? Is that format usable to give to the patient or other providers as a printed medical record?
7. After entering an encounter, it will display in the encounter page. Does this information display in a format that is acceptable to OpenEMR users.
8. Does the information carry to SQL-Ledger with the correct billing, provider and coding information.
This is a small subset of the areas that we would test if we were creating a form.
The encounter date used by the billing system comes from the form_encounter table which is maintained by the New Encounter form (and in a recent change by me, this form and table also maintain a "date of onset" which was conspicuously absent from the billing process).
I can’t think of any reason that other forms should be messing with these dates.
By the way the New Encounter form does not seem to provide for changing the encounter date of an existing encounter. Is this a mistake? Seems like we should allow for correcting an error here.
Changing the encounter date of an existing encounter.
I do not believe that medical professional liability insurers allow changing of an existing encounter date. I recommend contacting the insurer to find the obligations related to changing information on a medical record and what is allowed or prohibited.
I believe there is substantial legal liability in changing an encounter date. The problem is that the existing way that OpenEMR works is that anyone who adds a form after the actual encounter date will change the encounter date and mess up the billing process.
This happens when a less skilled user does something by mistake and it happens routinely for all practices actually using dictation for the "speech dictation" form.
The actual encounter date should key off the actual creation of the new encounter form. Adding subsequent forms should’nt change this date.
The date shown in the list of past encounters for a patient is not the encounter date (but should be). I expect it’s from the “forms” table. I believe this is a bug.
Incidentally I will be checking in a change so that the encounter date (as well as the onset-of-illness date) is viewable when you revisit the New Encounter form.
The list of past encounters seems to pick its date from "forms" using a descending order (last in is the datetime used), where ascending would the force the use of the correct date and time of the chief complaint recorded on "form_encounter"(first form in). Once recorded, this should be the transaction date and it should not be modified.
The only real exception would be a patient leaving after check in with the “form_encounter” but before actually being seen by the practitioner. Given the way the current billing is handled I don’t think this will be billed out at all. This should cause no harm assuming a bill is not actually generated.