Thanks!
1 Like
Getting close to having patient registration for portal ready to start a P.R for further development. While working on e-mail notification Iāve come to realize that this may be a show stopper for many potential users, especially smaller practices. Without going into the pros and cons of e-mail, I think it is safe to assume that email implementation for a practice can become daunting, to say the least, so, I purpose using a one time password or allowing instant limited access until a human can verify patient. Mainly for appointments and/or secure messaging.
Portal sessions are already isolated from OpenEMR sessions and through some pattern matching and careful finagling (my word of the day, use wisely)
we may be able to get by without security being compromised too badly.
Feedback anyone?
-btw: Should we collect SSN/ID during registration?
Hi @sjpadgett ,
I think most folks will want email confirmation (but ok to have the option of limited access if you think that will be helpful for clinics that donāt need to the email confirmation). Does seem like a bad actors dream, though, to have automatic access and hit the server with millions of new appt requests or secure messages (I say this because of some bad experiences on the wiki ).
Could always have a SSN field (since this is in OpenEMR), but make it clear that it is optional. Or could control it with a global. Or could just not have it. Up to you and can always be changed down the road.
-brady
I have been using the sunset patient portal for a long time and know it very well. On my site I have clients/patients do all their intake prior to booking an appointment and they book on the site. I have just coded it so that until they have entered all insurance information, or billing information, or guarantor information, completed my symptom assessment and the consent is signed they cannot book. So all the assessment tools and intake are already possible with the existing tools. I work with PayPal and that is very simple. I use an invoicing system plugin for Wordpress that keeps all clinical data on my server. PayPal only has money information. I have patients sign consents and ROIās on the site. Ninja Forms have signiture features. I have also made modifications that allow me to use Gravity Forms and CF7 forms. Gravity has wonderful tools built in for clinical assessments and tabulation. So, I also do comprehensive assessments, I have them attach to messages in cartpauj PM (now I am using Front End PM) and this gives the clients a copy and I have one to import into OpenEMR as a PDF. Some of my assessments are done using the LBF function and they import directly into fields within OpenEMR. There is a lot of functionality built into the existing system.
Appointments are an issue. I am using Easy!Appointments. This works fine with wordpress I have made a custom build of it found here. My build has many elements that are useful for clinical practice including an informed consent to opt in or out of email/sms notifications. Another nice thing about Easy!Appointments is that it syncs with Google Calendar for Business. With a BAA signed, this is a very nice HIPPA compliant feature. I have also included an option to limit the information sent to clients to just be date and time of appointment to increase confidentiality. The down side is that it is not integrated into the sunset patient portal webserve.php. We simply need an interface for this.
What is also needed is a pay ahead feature for the booking system. I have experimented with a few options and have not been happy with any. I am still taking insurance and different copays complicate the picture so I have put that off. I just invoice. It works.
Also, the fact that there is no sunset portal interface for scheduling interface is not that big of a deal. I use google calendar and my main schedule view screen. I book appointments in the Easy!Appointment Screen. I enter clients into the OpenEMR calendar by hand as patients show up. It is very simple and quick. If you are in a clinic, each provider can have their own google calendar and Easy!Appointments syncs with each. It works but an interface would be a nice addition to import all appointments for the day.
I have also documented some modifications to the OpenEMR side of the patient portal that are helpful. Those modifications are posted here. I am in the process of updating portions of my webserve.php file and those modifications are available here. The modifications are a work in progress. I need to replace CFDB. It is no longer working with CF7 and that is a bummer. But it still works with Ninja and Gravity forms for the time being.
Hi @Craig_Tucker ,
Lots of nice work. Would it make sense to get your changes into the main codebase? Also, Rod uploaded some code here for the wordpress portal:
Would it make sense for you to update that code also.
thanks,
-brady
Hi Brady,
I added the portal to my github. I do plan to move my mods onto that and sync. Unfortunately I started before Rod put it up. So I will get around to it, hopefully soon. I need to finish my work on the webserve.php and then I will transfer everything over. However, I have overdone the coding for now and I have to get to billing.
Craig
1 Like
Iām thinking it is safe to say and a pleasant fact that OpenEMR, is not Patient Portal poor. Making us not a take it or leave it solution.
Originally my vision was having all the bells and doodads for portal two including kioskās but after FHIR started maturing, Iāve decided that stand alone portal apps will become less needed/used and thought to turn portal two into more of a communication gateway and telemedicine. So instead of driving 25 miles to show my doctor a sore on my foot I simply send a picture in patient chat and he can tell me if the foot needs to come off or not
My registration work flow is similar to Cragās in that I will present a step wizard starting with basic name and e-mail then profile then insurance then basic history and possibly credit info last, validating as they go. Once done, captcha completes registration. Thatās a rather difficult process to automate a hack making e-mail verification not needed so much.
1 Like
I have a hook in eob posting to send an invoice to portal two that you may be able to use.
That sounds fantastic (given that I am in the middle of that process).
Check out interface/billing/sl_eob_search.php function notify_portal() and in sites/default/statement.inc.php osp_create_HTML_statement() for idea of how to create a statement specific to your portal needs.
So you are the one who did this. I looked at and even had it integrated into portal two when I started down a road to bring into OpenEMR proper when I stopped myself. I have this uncanny ability to start taking things way too far. Itās very nice and I really should reconsider using again but I just have way too many projects going on.
This has turned into a nice discussion. I have gotten the basics for the stripe CC function working.
@sjpadgett do you have the wizard working?
I will have the Stripe code posted by Wednesday of this week.
@juggernautsei Very Close, working the end point of credentials. You can see where iām at at https://www.opensourcedemr.us/portal
Mind you iām still pulling together pieces but youāll get idea. The last password panel is for test and not production.
@sjpadgett, I think this is a marvelous job. I should be able to add the other features she is wanting in the registration process.
@juggernautsei Once I get the exit panel worked out, adding steps is very easy and are set up like mini web pages.I think I will go ahead and open a working PR so folks can get to source. The OpenEMR password regen in demographics has issues and is not reliable, so I have to sort that out. However we can certainly point out we are closer today then yesterday(Some Southern wisdom to ponder)
1 Like
@juggernautsei
I just put up latest on my test server. It is the production version(close anyway) except that when you finish I pop up alert so you may get logon info along with the final close production alert.
Iām going to put up PR tonight and we can work from there.
What other steps do I need to add?
-btw sending to email is finished and turned on but I donāt have email capability on this test server. Iāll leave to you in the end to test that feature out.
Should I collect a patient signature as an option in registration? More immediate, should we allow a username/password reset for forgotten credentials.How important is collecting history in registration? Should we have hipaa agreement as portal use consent or the mere registration as implied consent?
@sjpadgett These are all good questions and I can give you my opinion on them but of course itās just that.
A forgot password is a great feature because nobody wants to send all day resetting passwords.
History is a great thing because in an audit or breach it may be the only thing the solves part of the mystery.
Yes, there the patient should sign/consent to the HIPAA agreement during registration.
The informed consent is a must have to bill the patient absent of his presence with a cc on file.
1 Like
@juggernautsei Thanks for the link and I agree with the premise. So while iām in this module may as well take all the way so I will add hipaa privacy agreement to a step, then history. The privacy agreement will come from my patient template feature in portal dashboard so each practice can setup their own. May as well put patient signature on file as well. History form should not be too involved, I believe, but cover the basics. I can leave that to some clinicians for guidance here.
Password reset first.
1 Like
The portal registration feature along with allow patient to reset password is now in code base. See above PR.
2 Likes