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. 
“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.
Thanks
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:
{EncounterForm:HIS}
{EncounterForm:LBFROS}
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.
Thanks
Sandra
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
https://www.open-emr.org/wiki/index.php/HOWTO:_Patient_self-registration_in_the_Native_Patient_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
https://www.open-emr.org/wiki/index.php/Sms_and_Email_Notification_Howtos
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.
It would require, though, that the patient has the opportunity to edit the information.
On another note regarding the UI and patient portal:
So, I believe this is what is missing. The distinction between “Patient” and “Profile”. Also the distinction between a patient chart, and a patient portal access chart. These need to be two different things, objects, CMS if you will.
In other words, OpenEMR EHR is the interface to manage patient data. OpenEMR-Patient-Portal, is the interface with which that data is exchanged. The latter may have multiple profiles for the same patient record, as children have two parents, who at times are divorced, and elderly dementia patients have multiple children who share the obligation of caring for them. As it is, with other systems, not OpenEMR necessarily, people share the login information to provide access to a patient chart.
Dr G,
Brilliant user needs analysis!!
What you’re describing is a Many-to-Many relationship, where potentially many (parents, grandparents, guardians) might need access to multiple (children/parents’) charts.
For relational databases, this requires a linking table with fields
- User account with access (Username) (Unique identifier1)
- Chart to be accessed (Unique identifier 2, or 61225,4, etc)
- (One Permission, eg to give others access, view, add info etc.)
Each Permission/Chart/User requires its own record.
Each user has a unique identifier
Each chart has a unique identifier
Each entry in the linking table has just one permission to one chart for one user.
Thus:
- Mary Smith (User ID with this access)
- Bill Jones (Chart ID Mary has access to)
- (Full control/add info/view) (Mary’s permission)
Changing this is a job for the elect guardians of the database and their high priests, because it could break many other things.
This interacts with another critically important table,
- User account with access (Username) (Unique identifier)
- Salted, encrypted password
- ‘Salt’ data
This is also the solution for the ‘Patient Portal creating (or NOT creating) duplicate charts’ problem because a parent or guardian should be able to create multiple dependents’ charts, but only if that’s clearly what they intend. If a Portal User who already has a chart tries to create a new chart this should default to them logging in to their OWN chart.
eg.,
Patient message:
You already have a chart at (Office Name.)
Buttons:
- Log in to your chart? (default)
- Create a new chart for someone else you take care of?
Great job describing the program behavior (you/we) need!!
Accurately describing what the program needs to do is critical to writing the code to do it.
(This may already exist, but I suspect it doesn’t, because of the problems we’ve seen with creating duplicate user charts from the portal.)
Fixing this should actually make the database guardians’ job easier because it solves a host of gnarly problems that otherwise get unsatisfactory patchwork solutions.
1 Like
thank you!
OpenEMR already has users with ACL. Ie provider: Dr G, front desk: Ms/Mr Receptionist, etc. So the samples/table is already there. In other words, OpenEMR already does it some where in its code.
Absolutely, the database is precious.
Thanks, it’s just my wish list!
OpenEMR already has users with ACL. Ie provider: Dr G, front desk: Ms/Mr Receptionist, etc.
What is ACL??
Not necessarily. It depends how permissions are set up, how Patient/User accounts get permissions, etc, etc…
Are patient users just a category of users like staff?
It all depends how the DB was set up.
There could already be a linking table (Many to Many) of staff users and permissions. Or the permissions can be squashed into the staff record. Making a linking table gives more flexibility, putting permissions in user files saves processing time.
Setting access to specific charts for patients/patient representatives is a different problem.
This gets very technical very fast, which is why I booted this to the DB maintainers. But by accurately describing the issues, we can make their job easier.
1 Like
Access Control Lists
It is already the way OpenEMR does user permissions
Yes, definitely. I agree.
It adds another level of complexity and security challenges. However, if this could be accomplished in OpenEMR, I could potentially allow an insurance company user to access a specific record. For me, it would eliminate the printing of charts for insurance company review. In other words. One user could be Blue cross/Blue shield. Wouldn’t that be cool?
Bit of a tangent from this thread, but I thought I would chime in and mention that patients currently don’t get ACLs. They are siloed into their own table (patient_data) which is separate from the users table. All the ACLs and ACOs work off the users table for now. @brady.miller, @sjpadgett and I have been discussing the need to create ACLs for them especially as we’ve been dealing with the FHIR implementation but so far we have not taken that step.
There is indeed a linking table with staff users and permissions and that is all handled via the acl and aco tables.
@ken did a bunch of work on creating specific segmentation of patient users to specific providers to deal with privacy and least privileges concerns but I don’t believe that is in core.
2 Likes
Also if you look at Users i’ve implemented user restriction there. Those that have permission to be available in portal, is set there. Also portal_user has to be set.
Having patient make up validating info in Registration is inevitable. To log in they still need to receive a onetime timed for one hour link in an email as it is now, it’s a fine line as to how hard we want to make it on the patient.
I don’t understand the need to merge patients. Simply delete if appears a failed registration. Besides the new patient credentials are tied to the new pid so a merge, depending on the direction of the merge, opens a whole host of potential data corruption because merge won’t catch everything. Too me, scary! Delete the new registration and email the patient credentials you will create for them.
I didn’t want do Registration in the first place. I only did what we have now because I had many user finally convinced me it’s so patient can make an appointment.
I really don’t mind you guys beating me up because most of it is good info to know but, where was everyone five or six years ago when I was developing! I spend a lot of my time of late doing documents templates and still want to do more once ONC is done. So please keep the comments coming where I truly don’t mind and will pick off some of these suggestion as I can.
Also try to remember I have spent 100 of hour contributing where we have vendors that modify for themselves and don’t contribute back. I’m grateful to one front end developer @benmarte who is writing a new front end to help complete the move I made to make portal a single page app.
So again please keep the convo going and thanks for taking an interest in improving portal. That is new to me!
1 Like
Well, FYI, I do love the patient portal. It is what has allowed me to go into this new adventure. It is not my intention to beat you up. I have just been documenting my experience. That’s all. Please, don’t take it as a criticism at all. You have done an awesome job!
In fact, you have created a whole separate UI for patients, essentially! An interface which could be duplicated for insurance companies, and for many other agencies.
1 Like
I actually envision that but my reason would be Occupational heath.
1 Like
everythings on the table in this thread
I was thinking, could the user be labeled/categorized as “Agency Rep”? This could be reserved as a label/category for a representative from say an insurance company, the workers comp board, the insurance adjustor, employers (in the case of occupational health for example)…
Here, also add:
Mary Smith (Chart ID Mary has access to)
Because Mary Smith could also be a patient in the practice, along with Bill Jones.
Your idea would still work though, right?
There would just be two entries (or more, if needed) in the linking table, right? One for her own chart, one for Bill Jones chart.