Form directory content question

OpenEMR Development
1

markleeds wrote on Friday, May 06, 2005:

I believe a form must currently follow the following standards:

1) form related files are stored in a directory with the same name as the form (any further references here to ‘the form’ will mean this directory and its contents).
2) the form will be placed in a forms directory, currently located at $webserver_root/interface/forms
3) the form will include the following files:

new.php: the page which you see when adding new encounter data.  An html form is generated whose action is to go to the save.php file.

save.php: the script responsible for saving data to the database appropriately by screening the submitted data and calling the appropriate form related functions.  As far as updating a database record, I don’t know if this is supported anymore.

report.php: responsible for rendering form data within a report of encounters for a patient.

table.sql: the sql statement for creating the table which corresponds to the data collected in the new.php generated page.

I believe that view.php is for updating records and I think I read somewhere that it was deprecated because we don’t want records changed.

I don’t know if info.txt is still required, but it should not be.  This is the file with a single line of text stating the name of the form.

I just want to clarify these points.  If anyone who has worked on OpenEMR for some time can contribute their knowledge on this subject, I would greatly appreciate it.  It is easy to make forms that work, but I don’t want to throw in extra garbage that isn’t needed.  Particularly, there is the long line in most save.php files dedicated to updating the record if the mode is set to update (I think this comes from view.php).  If updating form records is deprecated, we don’t need this.  If it is not, there should be a single function which handles adding new records and updating old ones depending on the parameters submitted.  It would be in forms.inc.  If we do not update forms ever, then it’s not needed and we can stop putting the sql update statement in save.php.

Thanks!

Mark

2

tekknogenius wrote on Friday, May 06, 2005:

In the new.php (or the deprecated view.php) there should also be a link to not save changes and return to prior form.

3

markleeds wrote on Friday, May 06, 2005:

An ideal setup would be to allow the form designer to create a single file which could be php or html whose only requirements would be that it’s form’s action is to go to a file named form_submit_controller.php.  This file would then check for the existence of save.php and handle it’s functionality if it is not there.  It would also handle creating the database table at registration by analyzing the contents of this single form file.  form_submit_controller.php would be the target for any action that would normally point to any of the individual form files.  The only information that needs to be passed to form_submit_controller.php is the form name so it knows which form it is dealing with.

Just an idea to potentially make form design a trivially easy task.  It would not break existing functionality because if one of the other files existed, form_submit_controller.php would just include it and do nothing else.

It may be a time consuming task to implement, so I’ll leave it alone unless anyone thinks it’s worth doing.

At least I’d like to clarify as much as possible what goes into a form as it stands now.

Mark

4

markleeds wrote on Friday, May 06, 2005:

Actually the above idea may be more trouble than it’s worth.  The form generating script is an easier alternative.

Another idea would be a type of form where the form and it’s fields can be modified endlessly without worrying about the database structure.

The way to do this is to save all field names and field data of the form to a single string by joining them together with a delimeter and then putting this string in a single database text field.  You then reverse the joining upon retrieving the data to get your field names and data back.  This would limit your ability to quickly search and do studies with your data, but it would allow for regular modifications and refinements of your forms.  I can create a version of the form script to generate this type of form.

Mark

5

sunsetsystems wrote on Friday, May 06, 2005:

I think the issue of forms is complex as a whole.  There are a lot of different ways to approach it.

It may work better to first discuss issues related to specific forms from the physician’s point of view, which will then lead to discussions about implementation, searchability and relationships between forms and other parts of the system.  The programming decisions should then be easier.

One thing I really like about this open source project is that we have physicians involved at a design level.

– Rod <rod at sunsetsystems dot com>

6

markleeds wrote on Saturday, May 07, 2005:

From talking to other doctors, I understand that the main concern is documenting the encounter in such a way that coding is appropriately done automatically and the note supports the coding properly in the case of an audit.  For example, the review of systems must contain pertinent positives and negatives for so many systems to qualify for a certain level of coding (04 or 05?).  This is unfortunately a weakness for me because in my six years of practice since residency, I have worked as an employee for a group with the majority of my patients being members of various HMO’s.  I understand capitation and risk plans, and I have some idea of the complexity of documenting and coding a patient visit, but not enough to confidently program it into the EMR.  The coding topic is complex and needs ongoing support, so maybe it is best that we concentrate on making sure that the capability is there for a vendor to provide support for the practitioner’s unique needs.

As far as my own personal needs, when I do finally make the move into my own practice and start using OpenEMR for real, I will need forms that have as much point-and-click as possible and minimal typing.  There should be lots of select boxes and popup menus with lists of text that is modifiable by the practitioner, possibly even individualized lists for each practitioner.  I would like to have quick forms for common conditions that are pre-filled with the most common choices so I can get the easy patients in and out quickly.  Imagine a UTI form that includes the patient’s complaint of dysuria for a few days, the typical symptoms of frequency, urgency, etc… the diagnosis and the prescription and even a popup window for printing the prescription.  So I load the form, print the prescription, submit the form, and I am done and also prepared if the patient brings up another problem.

I personally would like to have the ability to query my data in many different ways.  I would like to survey my data to print reports of the percentages of patients who have a certain diagnosis or a particular prescription.  Bar graphs and pie graphs might be nice.  Am I over prescribing certain antibiotics or antibiotics in general?  Am I prescribing too many controlled substances?  How many diabetics do I treat every week?  Questions that I find useful to study my own practice habits.

I would also like to generate reports to see what patient’s have pending labs, studies, referrals, missed appointments etc… to ensure that I am enforcing patient compliance and not letting anything serious slip by.  I might want to query the patient’s who have been diagnosed with a breast mass to be sure that all have received proper follow up.

I am currently working for a five office practice that does not have any interest in setting up an EMR right now because it will step on the toes of the billing company which also handles all of our IT work.  Our billing software is Windows based and runs on a remote desktop system that requires the use of a VPN which is, in my opinion, the most retarded setup I have ever seen.  When you print to the printer at your feet, the print job is executed on the server across town and sent back again.  If you touch their internet/network equipment, they accuse you of breaking something.  To implement an EMR, you would almost have to order a second broadband subscription for each office.

I would love to use OpenEMR in our practice, even in it’s current state, just so I don’t have to suffer through the trouble of patients following me from one office to another and never having their chart on hand.  I can’t tell you how many times I have had to play guessing games with patients, trying not to look like an idiot, asking them again and again about their history and medication lists.

That’s enough of my thoughts and problems.  Time for dinner, and back to work… :slight_smile:

Mark

7

jabellon wrote on Saturday, May 14, 2005:

I agree with Mark.
From a pediatrician point of view, we have two basics types of visits in  the office:
                             a) WCC = Well Child Care;  and
                           
                             b) SV / F/U = Sick Visits &/or Follow-Ups

On the WCC side we could have, for example:

1) WCC-2wo-form, WCC-2mo-from, WCC-4mo-form and so forth up to age 18 yo or else, each form with the specific questions and focusing on those areas of interest for that age ( developmental, nutritional, Vaccines, etc., as recommended by the AAP / AAFP / CDC )

2) On the SV / F/U side we could have the most common complaints we see in the office ie: URTI, LRTI ( including HAD, Bronchiolitis & Pneumonia ), OME, Sinusitis, AGE, Abdominal pain, a Generic form, etc.

With these we will cover almost 90 - 95 % of all Pediatric office visits. And I think the same applies to OB-GYN, FP, and even to Endocrinology, Pulmunology, etc
It will be a good idea if a previous WCC could be loaded up as a  “mold or template” for a following visit or to use a SV form for the corresponding F/U visit, only having to change those positive findings.
I have made and been using the above in paper for the last 16 years, I believe that using them in a computerize system will be a breeze.
Checking patients Wt., vs Ht., plotting them in the “curves” and calculating the child’s BMI. Also checking the Pts. BP against parameters as per Pts. age., ETC …
Also, adding capabilities to use the patient weight to calculate the dosage, after checking for alleriges to the said medication and from there to print, fax or email the Rx and at the same time print the patient advisory with regards to that particular medication, side effects, interactions, etc.
Sounds like I am dreaming, but I don’t think I am that far off, will OpenEMR be able to do all this, and maybe more ???

8

jabellon wrote on Saturday, May 14, 2005:

I agree with Mark.
From a pediatrician point of view, we have two basics types of visits in  the office:
                             a) WCC = Well Child Care;  and
                           
                             b) SV / F/U = Sick Visits &/or Follow-Ups

On the WCC side we could have, for example:

1) WCC-2wo-form, WCC-2mo-from, WCC-4mo-form and so forth up to age 18 yo or else, each form with the specific questions and focusing on those areas of interest for that age ( developmental, nutritional, Vaccines, etc., as recommended by the AAP / AAFP / CDC )

2) On the SV / F/U side we could have the most common complaints we see in the office ie: URTI, LRTI ( including HAD, Bronchiolitis & Pneumonia ), OME, Sinusitis, AGE, Abdominal pain, a Generic form, etc.

With these we will cover almost 90 - 95 % of all Pediatric office visits. And I think the same applies to OB-GYN, FP, and even to Endocrinology, Pulmunology, etc
It will be a good idea if a previous WCC could be loaded up as a  “mold or template” for a following visit or to use a SV form for the corresponding F/U visit, only having to change those positive findings.
I have made and been using the above in paper for the last 16 years, I believe that using them in a computerize system will be a breeze.
Checking patients Wt., vs Ht., plotting them in the “curves” and calculating the child’s BMI. Also checking the Pts. BP against parameters as per Pts. age., ETC …
Also, adding capabilities to use the patient weight to calculate the dosage, after checking for alleriges to the said medication and from there to print, fax or email the Rx and at the same time print the patient advisory with regards to that particular medication, side effects, interactions, etc.
Sounds like I am dreaming, but I don’t think I am that far off, will OpenEMR be able to do all this, and maybe more ???
Those are my two cents, anything I could share, except programing, I am willing to go for it.
Thanks
Juan

9

markleeds wrote on Saturday, May 14, 2005:

Dr. Juan,

Some of your requested features are possible now or would be fairly easy to implement.  I’d be curious to see the paper form you are using now and turn it into an OpenEMR form for practice.

Things like BMI calc can be done with javascript within a form.  The same with dosage for pt weight.

Checking drug interactions and side effects and stuff like that requires that the information be entered into the database.  It could be set up where you enter the data yourself for the drugs you use, or obtain the data to be entered by one of us by an automated script (not data restricted by copyright).

Maybe you could e-mail me a scan of one of your paper forms or, if you want, I’ll e-mail you my office fax # and you can just fax it to me and I’ll see if I can turn it into an OpenEMR form.

Mark

10

andres_paglayan wrote on Saturday, May 14, 2005:

Just commited a bunch of forms under contrib/forms
some new, some old that were in older OpemEMR releases.
vitals there makes BMI calc,
well_child_care covers all well child encouters from 0 to 18 and tailors the output according to patient’s age.

11

tekknogenius wrote on Sunday, May 15, 2005:

I have a growth chart almost finished (prints a plotted graph according to the CDC data). When it’s complete I’ll see if I can add it to one of the existing forms.