New patient search/add features

OpenEMR Development
1

sunsetsystems wrote on Thursday, April 30, 2009:

Hi All,

I have changed the New Patient form so that it now mostly duplicates the layout of the demographics form (minus insurance stuff which may come later).

Also this form now doubles as a patient search form.  So you can key in some field data and click the Search button, and it will pop up a list of matching patients.  If you see the one you were going to add, then just select it and proceed.  If not, close the popup and continue with entering the new patient.

As this is a fairly big change, I have made it conditional.  The switch $GLOBALS[‘full_new_patient_form’] determines whether it is used.

Comments appreciated.

Rod
www.sunsetsystems.com

2

bradymiller wrote on Thursday, April 30, 2009:

hey,

Interesting. Overall concept seems better to input all info at beginning and allow search check for same users.  Some issues:

1) The Unassigned in the surname field is really awkward for some reason (can’t just default to Mr?).

2) I’d now highly suggest clearing the state and country lists (make just text box) and make the provider optional. Not even being able to add a functional user before learning how to deal with these things will likely lose potential users. Users can actively add these things if they want later on.

-brady

3

bradymiller wrote on Friday, May 01, 2009:

Also, I’d probably just put the insurance option in there also.
-brady

4

aperezcrespo wrote on Friday, May 01, 2009:

Hi
  I may be confused (actually that’s my normal state) but I thought that if various (I dont now how many) fields were the same as another patient we’d be able to catch duplicates before they got in.  I thought it would search and display results and then ask if I REALLY wanted to create this patient.

I think this had been discussed somewhere.

I don’t think OB-Gyn would like a default of Mr.

Also, could we not auto fill in state and city/town by entering the zipcode only?  This would reduce data entry and errors.  Here is a project which has zips in MySQL http://zips.sourceforge.net/.

Alfonso

5

omo66 wrote on Friday, May 01, 2009:

By default the provider field is required. This will require many clicks to register a patients. May be all required fields should inside that first box .

PS:
I installed last CVS as openemr4 on testing server to test above.
The installation failed due to globals.php: it failed to make $web_root = "/openemr4";  (it was written as $web_root = "/openemr":wink:

Thanks

6

bradymiller wrote on Friday, May 01, 2009:

Omar,

I’m assuming your using linux cvs snapshot with following instructions (if not, let me know; if this is a bug want to squash it):
http://www.oemr.org/modules/wiwimod/index.php?page=LinuxGenericOpenEmrInstallCvsSnapshot

In step 2 of the installation, did you set the ‘Relative HTML Path:’ entry to /openemr4 ?

-brady

7

omo66 wrote on Saturday, May 02, 2009:

I did not set the ‘Relative HTML Path:’ entry to /openemr4 in step 2 of the installation.
My error sorry. I thought all defaults are based on  initial setup directory name.
Thanks for the great work.

8

bradymiller wrote on Saturday, May 02, 2009:

hey,
Actually that’s a good idea to try to automate the web path also. If I have time, I’ll try to automate it.
-brady

9

tmccormi wrote on Wednesday, May 06, 2009:

My general feeling on the New Patient form is that it should be managed in the layout tool so the the end users can choose exactly which data *they* what to have display on that form and which of those are "required/optional" from the entire demographic section including misc and insurance.

My 2 bits,

Tony

10

ideaman911 wrote on Wednesday, May 06, 2009:

I am entirely in agreement with Tony re the “requirements”.  Newbies have no idea what that means, and CERTAINLY have no idea how to fix it.  I suspect most of the users of OpenEMR are small practices, so that “requirement” is absurd for them.  And for multi-provider practices, how many have the patient seen by both MD and NP/PA, which makes the field silly?  Let’s be INclusive, and make the initial exposure as simple as possible.  Once they get deep like us idiots, they will already be hooked, so it will be too late for them to get away anyway :wink:

Searches should by definition treat "undecided, unspecified, etc" as meaning "Any", so the lack of explicit "Mr." should still find BOTH male and female.  Why is this even a question?

And while I’m on a soapbox; EVERY dropdown should have the ability to add RIGHT THERE.  If users are authorized to be there in the first place, PRESUME they are smart enough to try to use an existing choice first, but let them add to that as readily as possible.  We “programmers” have NO IDEA what the practice needs will look like over time.  Requiring it to be hidden in an Admin - Lists form is more likely to cause rejection of usage than enhanced practice benefits.  If clients want locks on such things, let them set switches for THEIR needs, but default should be as open as possible so newbies can learn.  They will ask for the locks later, perhaps, and then you guys can make money from them setting those :wink:

Joe Holzer    Idea Man
http://www.holzerent.com

11

tmccormi wrote on Wednesday, May 06, 2009:

Joe,
  Deep breath :slight_smile: - That ‘Any’ search you want is coming.  It’s working well for us in production.

  I agree with the List issue, [Add] should be a regular feature on all lists or, at least, the ability to Add should not require going to PhpMyAdmin and should be documented.

  Having salutations like Mr. are good if you are planning on doing letters and mailings.

Tony

12

bradymiller wrote on Wednesday, May 06, 2009:

hey,

On a related issue:
If nobody disagrees, I’m gonna make following changes to default install:
1) Make the state and country fields blank textboxes
2) Make the provider field optional

I see no reason why we are tripping up new users with this. Are there any good reasons not to do this as default?

-brady

13

tmccormi wrote on Wednesday, May 06, 2009:

Can you make the ‘provider’ field also say what it is, ie: REFERRING Provider, all my customers thought is was used to pick who the patient was assigned to, but the layout tool comments refer to it as referring provider and it uses the address book Provider NPI list option, so…

And I agree with the rest.

–Tony

14

sunsetsystems wrote on Wednesday, May 06, 2009:

There’s no requirement to go to phpmyadmin to add to a list.  The Admin/Lists interface provides for that.

Rod
www.sunsetsystems.com

15

sunsetsystems wrote on Wednesday, May 06, 2009:

The purpose of a list is to enforce uniformity where the choices are limited.  I would think states fall into that category.  I’d suggest instead adding all US states to the list of states.

Rod
www.sunsetsystems.com

16

sunsetsystems wrote on Wednesday, May 06, 2009:

Agreed that insurance should be included.  But otherwise the New Patient form, as recently modified, *is* managed via the layout tool (using the demographics layout).

Rod
www.sunsetsystems.com

17

bradymiller wrote on Wednesday, May 06, 2009:

hey,

On a related issue:
If nobody disagrees, I’m gonna make following changes to default install:
1) Make the state and country fields blank textboxes
2) Make the provider field optional

I see no reason why we are tripping up new users with this. Are there any good reasons not to do this as default?

-brady

18

sunsetsystems wrote on Wednesday, May 06, 2009:

The search already treats "unspecified" as "any".  Obviously this works best if there is no default value for any of the drop-lists.

I have no objection to adding the ability to add to a list from a dropdown that references it.  However the appropriate administrative rights should be required.  You don’t necessarily want data entry clerks making such administrative decisions.

Rod
www.sunsetsystems.com

19

bradymiller wrote on Wednesday, May 06, 2009:

Sorry about repeat message above.

Rod,

  Even with all the states, then will be an issue for people outside the states.  Making these blank is the least unobtrusive for new users figuring things out.(an aside, these are places where widgets would work very well that allow saving new items to the list as they are entered in)  As users gain expertise they can use layouts/lists while avoiding the suhosin bug (by the way this suhosin bug is nasty; see what happens to the layout of contact information when you try to save a layout on the cvs demo).

-brady

20

blankev wrote on Wednesday, May 06, 2009:

Rod,

OpenEMR is supposed to be(come) an International Medical program.

For the US "States" translates into 52 or more States. (But see also the different location tables)

For the Netherlands Antilles I use:

Name of the Bario for City (Matancia, Banda Abao, Boca, Willemstad Center, …)
Name of the Island for: State (Aruba, Bonaire, Curacao, St Maarten, St Eustatius, Saba)
Name of Country: Netherlands Antilles, Aruba, Netherlands etc.

(With Google earth I hope to get the future epedemics in view with these local specifics)

See: Mexican Flu Statistics on the Internet   http://flutracker.rhizalabs.com/

So with separate Country inserts you can have whatever is applicable for your Medical setting. (Same as for for now used for Languages) A separate spreadsheet (Database) with all Country names, States, City etc and include whatever you want, seems for me more suitable for an International Medical Program.

Same goes for Security, Coding of medical interventions ICD9 versus ICPC, Payments structure etc. Laboratory interventions, medical specializations… etc.

Although MySQL can handle huge Tables and Databases it might be a bit to much to include every optional Coding, Demographics etc in future install versions and so I would think preferences on a place/situation to place-basis is needed for the future of Internationalization.

Pimm