V6 Documentation wish list

So, going into the demographic layout form and setting this field to be excluded from the portal is not working. Hmm.

I am going to administration>forms>layouts>demographics and selecting “exclude from portal” under the options column. What am I doing wrong?

Hi @gutiersa - yes, SJP mentioned elsewhere that you can get into the demographics layout in the EMR (Administration/ Forms/ Layouts) and add an option for that datum to exclude it from the portal. This method keeps it displayed and usable in the EMR demographics screen.
Pretty cool, huh?

  • HT
1 Like

Yes, I definitely love working with OpenEMR. It is pretty cool.

But it is not working for me this time. Dunno why. It works in other forms though, let me upload some images.
Actually, let me start another thread. This is not really part of the wish list. I mean, it is and it isn’t

If you don’t want patient to see items from Demographics then use:

You may need to get patched up. I’m unsure when I fixed to exclude in the:

I know worked since 5.0.2 for profile edit.

I am using version 6

I created a new thread also:

this is my setup:
I am using OpenEMR version 6.0.0 in a FEMP stack:
FreeBSD 12.2
Nginx 1.20.0
Mysql 8.0.25
PHP 7.4.20

I wonder if it’s my table. Is there a way for me to compare my table? Before my upgrade, I was running 5.2 though!

@gutiersa - I was amazed to find how little up to date documentation there is on the portal. The newest description of the whole thing is that initial section on the page ‘patient portal’, which talks about OEMR 5.0.
So I set myself to write one for OEMR v6.0+, which will draw heavily on the forum posts SJP has contributed about all the updates that have been made.

Seems to me that those things you’re looking at doing- editing the help.tpl, the workaround for the e-sig, etc- are probably very common concerns and would make good add-on docs to a primary portal doc. You ought to keep notes on how you accomplish them and write them up for the wiki!

Yes, this is exactly my plan, to write a tutorial. However, I realize I should probably be writing it as I figure it out. Eventually I will forget which were my initial challenges once I figure out openemr.
It is just a slow process for me, and there are not enough hours in the day.
The development is just way fast!

Beautiful job on this wiki page:


I modified it by adding a few links to this paragraph, at the end.

“* Note: In order for the patient to be emailed their portal login credentials an email address needs to be set in Administration->Globals->Notifications->‘Patient Reminder Sender Email’ (not pictured) and the SMTP server needs to be set up. See instructions for that elsewhere. (Sms and Email Notification Howtos, Administration Globals for example.)”

Do we have any other setting-up-SMTP tutorials? If so, kindly point them out. I will happily add them as a link. If the tutorials are outdated, then also let me know. I will create a new page for version 6 and with your help I will update it. I am currently working on setting up my own email which is not working.


1 Like

Is there going to be new user guide for 6.0.1? Seems unlikely to me, so might be more accurate to rename it “OpenEMR 6.0 Users Guide”, and preferably “OpenEMR 6.0 User Guide”.

1 Like

How about “Submit to your provider” or “Submit Form”

Also, once the forms have been submitted and I have added them to the patient chart, in the documents, the patient can no longer modify them, correct?

Yes they’re locked but can still be download, printed or viewed.

1 Like

It sounds like this is a UX problem. How do other websites prevent duplicate signups?
I know when I enter my email, if it already exists in their system, I get directed to the login page (complete with ‘Forgot Password’ link) or at least an error message.

Similarly, if you require forms to be signed, make that a requirement to submit the form.
This requires conditional logic and or entry validation in the patient portal forms. Is this supported?

1 Like

How do I make the signature a requirement to submit the form?

thanks for your reply

Ths gets back to a small UX point on “required fields.” I would not have interpreted the little green ‘thumbs up’ as meaning "this field is required."

  • The little icon for required items (circle at right) will be used in other portal registration screens.


What I’ve seen on other website forms is a label saying something like
"Fields marked with an asterisk * are required."
If we’re going to make a field required, we need to tell the user in simple terms.

How do I make the signature a requirement to submit the form?

Dr Gutierrez, when you say signature, do you mean the '‘signature on file’ image or an electronic ‘signature’?

whatever makes a field required on the included forms should make it required for the “signature.” I don’t know how that’s coded, but looking at the form source code should tell you.

I’m also curious at how you did the setup to allow patients to self -register multiple times. However you did it, it SHOULDN’T be possible, so you found a real bug which should be killed!

Dup check should catch and if they’re still able to
reregister well, your patients seem to be more clever than you’re giving them credit

I wonder if this is the ‘feature’ that allows multiple people to use the same email. Since anyone can get their own PERSONAL FREE email from multiple providers, IMO this is a ‘feature’ that should be off by default. And maybe completely unneeded. :upside_down_face:

“When engineers make something more foolproof, God invents better fools.”
Thank you for clarifying these points, Thanks also to whoever wrote the new documentation for the patient portal!

1 Like

OMG, this is so useful, and I am only in the third paragraph.
I will go back and double-check the wiki. I would like to make sure these things are readily accessible for everyone!

Is it possible that I my setup has errors?( BTW, this was as of 5.2, I have not tried with version 6. I will test this problem in my version 6 and report back.)

Initially, with previous version, my patients were making mistakes with their date of birth. For example, I had patients born, say, in October 3, 1950 enter March 10, 1950 for the first or second user. This creates, not an actual duplicate, but a duplicate chart for the same patient. (perhaps, it is a good idea if we write the information to the screen for the patient to proof read it prior to submission by the patient, and prior to chart creation? This will give the patient the opportunity to verify the information for correctness prior to hitting that submit button!)

Other times, one chart would have the middle name, the dup wouldn’t.
I am unable to recall other circumstances. I ended up just disabling the feature. What I now do, is create the user by entering their fname, lname, dob, gender, and email address. Then, I email them the information with instructions.

I mean the ‘signature on file’ image.
In my case, there are a lot of documents for the patients. People just don’t want to fill out so much paperwork. They skip a lot of steps. I am going to opt for using the electronic signature disclaimer.

Has anyone tried to make a patient portal form using two different layout based forms?
For example:


This is just not working for me. The patient portal only renders the second form, in this case the ROS form followed by a big space.


I don’t think there’s an actual tutorial.
Using gmail’s smtp is described in a forum post

and the wiki doc for patient self- registration in the portal
links to that post. But the process is not reproduced in the wiki article.

Other than that, the only instructions for SMTP setup I can find are in
which is pretty old, as it talks about globals to set in OpenEMR v3 and 4.

I think you found a gold nugget here:

good idea if we write the information to the screen for the patient to proof read it prior to submission by the patient, and prior to chart creation?

That would be a good “User Interface” tweak for user input. Whenever we want accurate input, it’s a good idea to ask them, “Is this right?” and make it easy for them to correct errors.

The primary identity and security measure ends up being the patient’s primary contact, whether email or phone #. That’s another reason NOT to routinely allow multiple people to use the same email.
For families with children or other dependents without their own emails, the primary key could be “email & FN & MN & LN & dob” because people have this regrettable tendency to give children almost duplicate names.