Read about OpenEMR's Response to the COVID-19 Pandemic at https://www.open-emr.org/covid19/

Version of PHP in OpenEMR

I have a plan to degrade my version of PHP to 7.3. However, because of OpenEMR’s plan to achieve advancing MU, should I? I know that we have in other forum conversations have this discussion, and I know that some use the bleeding edge OpenEMR which uses PHP 7.4 and Mysql 8. However, I was not able to. It is not that I am complaining or whining, but because I am a non-Linux user in the Unix community, I figured I could be the weak link, and perhaps we could try to make the software its best in preparation for the next MU stage and truly OS independent.
It is my opinion that all the programming going on today should be done keeping in mind MU such that no re-writing needs to be done when Openemr takes on MU. BTW, I do know that the work is already being done out there.

Finally, just to let you know, I have worked for the last 3 years in a company that did use stage (latest) MU. Which means that I can help.

Opinions?

In the meantime, anyone can help me with these error messages I would be grateful:

TypeError: placeSignatureButton is null
URL: https://openemr.smg.network/portal/sign/assets/signer_api.js?v=51
Line: 712 Column: 9
Error object: “{}”

The error above I get after patients submit documents via the portal. Once I sign the document and attempt to enter it into the patient chart, I get the above error and I must click ok several times before it disappears.

TypeError: Property ‘handleEvent’ is not callable.
URL:
Line: 0 Column: 0
Error object: “{}”

These errors may not have anything to do with PHP version, but that is the only thing I can think of.

thanks for reading

This is not caused by PHP 7.4. It’s a JS error. Looks like signer class is not reloaded after save. Haven’t seen this error in a very long time. I’ll look into when I get a chance.

I think PHP 7.3 is dead to the world and project admins over there are wishing they never heard of that release.:slight_smile: Wait! or was that 7.2… who can keep up!
I’d stick it out with 7.4 unless there are compelling reason 502 doesn’t work on 7.4 which i’ve not seen.

Great, thanks for the advice. I will follow it.
Once I figure out my problems, I will change the title of this thread then.
I really am a one woman show. I am heavily depending on my patients using the portal. I am creating forms which when I have finalized and are working, I will share.
We should have a form repository like OpenOffice does with templates, such that the OpenEMR package need not grow too big, no? (anyway, that may be for another day/thread)

What does “AVM confirmed” mean? In the appointments in the calendar.

Unknown. That got sneaked in when I wasn’t looking. Maybe someone else knows.

Agreed, something needs to be done in this regard. I’m working on an exclusion of allowed portal profile items(gender, race etc) feature now so will prob look into advancing other areas of protal while i’m there.

I have always hoped other devs would pick some of these features up and expand them but, not so far. I feel so lonely.:slight_smile:

1 Like

Don’t be, I’m here now! Lol (the non-programmer)

I can volunteer a server for a repository, I am not sure how to do it, however, I can find out!

How about the following error? I get this when I attempt to print a prescription from the prescription interface. I will upload a picture if you need one. The last time I had a similar error you felt it was the portal not being compatible with PHP 7.4:

An error occurred
An error occurred during execution; please try again later.
Additional information:
Error

File:

/usr/local/www/openemr/interface/modules/zend_modules/module/PrescriptionTemplates/src/PrescriptionTemplates/Controller/HtmlTemplatesController.php:40

Message:

Cannot call constructor

Stack trace:

#0 /usr/local/www/openemr/interface/modules/zend_modules/module/PrescriptionTemplates/config/module.config.php(33): PrescriptionTemplates\Controller\HtmlTemplatesController->__construct()
#1 /usr/local/www/openemr/vendor/zendframework/zend-servicemanager/src/ServiceManager.php(764): PrescriptionTemplates\Module->PrescriptionTemplates\{closure}()
#2 /usr/local/www/openemr/vendor/zendframework/zend-servicemanager/src/ServiceManager.php(200): Zend\ServiceManager\ServiceManager->doCreate()
#3 /usr/local/www/openemr/vendor/zendframework/zend-servicemanager/src/AbstractPluginManager.php(152): Zend\ServiceManager\ServiceManager->get()
#4 /usr/local/www/openemr/vendor/zendframework/zend-mvc/src/DispatchListener.php(102): Zend\ServiceManager\AbstractPluginManager->get()
#5 /usr/local/www/openemr/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Zend\Mvc\DispatchListener->onDispatch()
#6 /usr/local/www/openemr/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\EventManager\EventManager->triggerListeners()
#7 /usr/local/www/openemr/vendor/zendframework/zend-mvc/src/Application.php(332): Zend\EventManager\EventManager->triggerEventUntil()
#8 /usr/local/www/openemr/src/Core/ModulesApplication.php(105): Zend\Mvc\Application->run()
#9 /usr/local/www/openemr/interface/modules/zend_modules/public/index.php(52): OpenEMR\Core\ModulesApplication->run()
#10 {main}

All above is one single message

I put fixes in patch 4 for portal and PHP 7.4 and know of a couple sites running under this.
Using Zend prescription module is an unknown for me however you may be able to get around by adding
& ~E_DEPRECATED & ~E_STRICT
to php ini error_reporting line. If not then I suppose one has to go, Zend or PHP 7.4. I am fixing the entire CCM module for MU but for v6.0.

I already have this
I am in production

Sandra, Are you in production now or getting ready for production?

this is my error entry:

error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED

I am in production
Don’t have a lab, but will be setting one up, I hope

Like I was telling @juggernautsei I worked for a company that used an EMR which already has the MU pretty advanced. They however are proprietary. I am a believer in opensource. I would like to contribute toward MU. I may not code anymore, but I can contribute with my experience, no?

Technically, all you would need is keep me in the loop, I test drive it, then I tell you what I think, like here:

This appears to be broken in PHP 7.2.4 as well so, I’m surprised not many others have not complained.
I don’t know if it’s worth fixing at this point! Moreover, This is a Matrix module and wondering if they fixed local!!!

Well I believe they are revamping the prescribing module altogether. It is not that I need it, I am not printing anything anyway. I just figured I bring it up since we were on the topic of php version. The other tabs in the same window give similar errors.

I am using allscripts as the weno prescribing is not yet working for me, and I can continue to do so while the errors are sorted out. It does double my work though, and as I get busier this will be a problem.

BTW, I have one database in production, but I do have other separate openemr installations that are not in production. Did you want me to try anything out?

I am not sure where to put this, if it is a feature request, if it is bug, if I should place it in developers, should I open a new thread?

When I tried to get my patients to register themselves, some patients ended up creating 3 different accounts in my medical record. Now I have to merge them. Hence I now ask them for their DOB, email and names. I set up the patient then I set up the portal, then I send them the information by email and have them login.

Is it possible that the system double check for duplicates by verifying the email? In other words, like WP allowing only one account per email? I know patients will tend to then use a second email, hence we will need several checks. There will need to be:
DOB
email
name, last name
What do you think?

It’s an iffy!:slight_smile: First, last and DOB should be enough. Not sure how strict we should be and sounds like folks are forgetting passwords. Make sure you can send emails for password changes. Meantime, open an issue. This is the sort of stuff @tywrenn loves diving into and maybe he’ll take a look but, if not, i’ll look at…

It will not be enough for MU trust me. I take care of elderly folks and I am asking them to even have a smart phone, don’t forget that. It is a matter of inclusion.
Some patients were getting their dob wrong, making errors such as switching the month for the day, some where entering the year before, for example I had the same patient with 3 different date of births:

20        name, patient                                             10/06/1945
21        name, patient             xxxxxxxxx                       06/10/1946
22        name, patient             xxx-xx-xxxx                     10/06/1945

Not to mention that the patient’s last name is hyphenated and she has a middle name, it can get complicated from what I learned (the hard way, I have tons of duplicates)

The next question is then, why is this happening? Shouldn’t the SS# get checked for the hyphens or something. I forget what that is called is programming.

Not yet, I am unable to send emails for password changes. In fact I have this error out there:

Which I have not been able to fix.

Sandra, Looks like I wasn’t testing email and only collecting.
What are the chances that family members will want to use the same email address?

I think i’ll initially reject if email and dob. Then do another validation after profile(before insurance) is finished using first, last, dob and maybe gender or postal code. If these match then user is reupping and will reject.

Hmmm I hadn’t thought about that, it is possible, I have some elderly patients whose daughters are signing them up for the portal using the daughter’s email.
However, I do have a patient who has no email at all. I set up her portal by just using her full name in the email field. It looks like the email field does not check that the data entered is consistent with email address format.
What I mean, is this, in the email field I just used this for example:

sandragutierrez

I wonder how WP does this. It would be interesting to look over that code.