Onset date in add_edit_event enc form create

OpenEMR Development
1

tmccormi wrote on Monday, March 05, 2012:

The automatic creation of encounters from the calendar appts is hard setting the Onset date to be the “event date”, ie the appting date.  This is bad, Onset/Hospitalization date must be blank unless it really is a one of those, and that should be set by the user not by the calendar tool.

I’m going to fix this and commit it tonight unless someone thinks otherwise …

Heres the code:

          addForm($encounter, "New Patient Encounter",
                    sqlInsert("INSERT INTO form_encounter SET " .
                        "date = '$event_date', " .
                        "onset_date = '$event_date', " .
                        "reason = '" . formData("form_comments") . "', " .
                        "facility = '$facility', " .
                        "facility_id = '" . (int)$_POST['facility'] . "', " .
                        "billing_facility = '" . (int)$_POST['billing_facility'] . "', " .
                        "provider_id = '" . (int)$_POST['form_provider'] . "', " .
                        "pid = '" . $_POST['form_pid'] . "', " .
                        "encounter = '$encounter', " .
                        "pc_catid = '" . $_POST['form_category'] . "'"
                    ),

-Tony

2

yehster wrote on Monday, March 05, 2012:

I agree that not setting the onset date automatically in this situation is the correct thing to do. I’d like to suggest that while you are making this change it might be a good time to write a new function to create an encounter as a step towards modularizing this functionality.

3

tmccormi wrote on Tuesday, March 06, 2012:

Good suggestion.

Though it doesn’t look like it ‘addForm()’ is a common function, from forms.inc.  The third argument returns the form_id of the “header” that was created in form_encounter by the imbedded SQL.    While I think this is cute, it’s a tad hard to follow.

That said, I have the time to delete one line of code from that SQL statement.  Which will fix this issue, I don’t have the time to come up with a better,  more elegant solution at this moment…

So, I’ll fix it the simple way, an perhaps, in a moment of inspiration some evening in the future I’ll do some modularizing…

We (ie MI2) have a very modified version of this file that can call the Letter Template popup to produce a appointment notice that can be saved to the document tree, printed or emailed …  It needs some prettying up and permission from the customer to share, but perhaps when we get to share that code we’ll do some other clean up work.

-Tony

4

tmccormi wrote on Tuesday, March 06, 2012:

and done …

commit 336268fdc4f7f84180fd0f10a1e08d8e826abd38
Author: tmccormi <tony@mi-squared.com>
Date:   Mon Mar 5 21:44:16 2012 -0800

    Remove default of Onset Date = Visit date in calendar encounter auto creation process

5

sunsetsystems wrote on Tuesday, March 06, 2012:

Tony, why don’t you discuss code sharing with your customers up front.  In my experience, after talking with them a bit about the GPL and advantages of upgrading without having to port a lot of custom code, most are happy to give blanket permission.

Thanks for the contribution!

Rod
www.sunsetsystems.com

6

tmccormi wrote on Tuesday, March 06, 2012:

I always do and they almost always agree.  In this case it’s a “old world” kind of company and they agreed that it might be OK, but not until we finished the project, which has been ongoing for 6 months and will be for a while yet. 

In this case it’s not an ordinary OpenEMR medical practice use case, it reusing OpenEMR as a part of a much bigger service and quite of lot of OpenEMR code has been removed or repurposed, so it’s not a simple upgrade issue, but some real gems are coming out of it and I do want to share them.

Remember… my company name is Medical Information Integration … not OpenEMR Sales, Inc… :slight_smile:

-Tony

7

bradymiller wrote on Tuesday, March 06, 2012:

Will place this in the next patch also.
thanks,
-brady