ardenwong wrote on Saturday, February 04, 2012:
Hi all,
Would like to clarify is it possible to install on a ‘shared hosting’? If so, how?
Or VPS hosting, Dedicated Server necessary?
I’m now using a shared hosting from Hostgator.com and it seems it doesn’t work due to restricted root access.
Thanks in advance.
tmccormi wrote on Sunday, February 05, 2012:
Several of the companies listed under professional support provide OpenEMR hosting services, I would recommend choosing one of them. Others have chosen commercial hosting services with success, but you need very full access to the system.
Tony
suitable1 wrote on Thursday, February 09, 2012:
What in Open EMR would require root access? We’re planning to use a shared host, but right now we’re playing with a local server to learn the package.
juggernautsei wrote on Friday, February 10, 2012:
One of the things I can think of is the perl scripts to load the ICD-9 and CPT4 codes. There are a host of other things that you would need root access to do. The best thing if your going for a hosted solution is to buy a hosted server. If you buy full access to a hosted server you will have better success.
Contact me offline and tell me what your plans are and see if we can work a deal.
suitable1 wrote on Friday, February 10, 2012:
Well, if adding codes to a database requires root access, we may have to rethink our choice.
yehster wrote on Friday, February 10, 2012:
Sherwin is incorrect. You don’t need *root* access to enter the codes.
For ICD-9 codes, the sql to insert into the codes table is pre-packaged now, so all you need is mysql access.
The perl script for CPT codes does again does not need root. Shell access that allows you to run perl is different from root access. Also, if you didn’t have shell access on the host machine you could always run the perl script on a different machine and then use the generated sql to load the code if you only had database access and not shell access.
Where true *root* access would actually useful is if php settings don’t match the required settings and you wanted to change php.ini. If components such as cURL or DOM/XML were missing from the server, the easiest way to get things working would be with root.
suitable1 wrote on Sunday, February 12, 2012:
OK, I decided to try to install on the shared host to see what issues I might have. I followed the instructions for the basic Linux install. The script failed when it tried to create the database. The good news is that the hosting company provides utilities that handle most activities that might require root access. I was able to create the database and user via the utilities. The file utility was use to change the file access permissions. There is also a mechanism for establishing a custom PHP.ini without root access.
I have been able to complete the installation and login to Open EMR. We’ll see if everthing works OK for testing in the coming week. We intend to use client-side SSL and encrypt the database when we go live.
blankev wrote on Sunday, February 12, 2012:
Let us know on you how you continue and where you encountered obstacles so we can learn.
Backup and synchronisation
Safety of the clients information etc….
Tnx,
Pimm
jojohit wrote on Monday, February 13, 2012:
I’ve successfully tested OpenEMR on a VPS. A minimum VPS subscription is cheap, only about $15/month. But the problem with VPS’s is that there are many variations depending on which linux flavor the host is using and what are the limitations on their hosting. The other problem with a VPS is that it is a shared OS hosting, meaning each VPS subscriber is using the same running kernel but on their own userspace. It is not a fully-isolated virtual environmen as tthere could be memory leak and directory permission issues. In the end I migated away from the VPS I was hosted on because they do not have a good SLA; when the host is down I do not get an email, at the least. Also, the host company cannot give us a confirmation of HIPAA compliance so it is very risky to subscribe to them. Anyway, with VPS you are sharing an OS, therefore HIPAA security is out the door right away. What is really needed on a virtual hosting is a dully-dedicated virtual subscription like VMWare, Or HyperV or Amazon implementations. I look forward on more development of the virtual appliance manual which is based on Ubuntu. I hope that each and every Ubuntu configuration and solution to make OpenEMR systems documented on this HowTo. I’ve used it for initially learning how to setup my first OpenEMR sand box.
JP
ardenwong wrote on Wednesday, February 15, 2012:
Thank you for the reply from everyone. I’ve now installed the OpenEMR on Hostgator VPS.
However, i have not been able to add new patient or facilities. The error message is like this:
ERROR: insert failed: INSERT INTO patient_data SET pid = ‘1’, date = NOW(), `title` = ‘’, `fname` = ‘John’, `mname` = ‘’, `lname` = ‘Test’, `pubpid` = ‘jt123456’, `DOB` = ‘1950-01-01’, `sex` = ‘Male’, `ss` = ‘’, `drivers_license` = ‘’, `status` = ‘’, `genericname1` = ‘’, `genericval1` = ‘’, `genericname2` = ‘’, `genericval2` = ‘’, `street` = ‘’, `city` = ‘’, `state` = ‘’, `postal_code` = ‘’, `country_code` = ‘’, `mothersname` = ‘’, `guardiansname` = ‘’, `contact_relationship` = ‘’, `phone_contact` = ‘’, `phone_home` = ‘’, `phone_biz` = ‘’, `phone_cell` = ‘’, `email` = ‘’, `providerID` = ‘’, `pharmacy_id` = ‘0’, `hipaa_notice` = ‘’, `hipaa_voice` = ‘’, `hipaa_message` = ‘’, `hipaa_mail` = ‘’, `hipaa_allowsms` = ‘’, `hipaa_allowemail` = ‘’, `allow_imm_reg_use` = ‘’, `allow_imm_info_share` = ‘’, `allow_health_info_ex` = ‘’, `allow_patient_portal` = ‘’, `occupation` = ‘’, `language` = ‘’, `ethnicity` = ‘’, `race` = ‘’, `financial_review` = ‘’, `family_size` = ‘’, `monthly_income` = ‘’, `homeless` = ‘’, `interpretter` = ‘’, `migrantseasonal` = ‘’, `referral_source` = ‘’, `vfc` = ‘’, `deceased_date` = ‘’, `deceased_reason` = ‘’
Initially I had problem with adding user and was solved by setting the Default Password Expiration Days (Globals - Security) to non-zero value.
Could someone enlighten me with this Add Patient problem?
I’m not in the US. All the US-specific fields I leave them empty. I entered only the basic ones: First Name, Last Name, Date of Birth & Sex, and then Create New Patient.
Thanks a lot.
fkasmani wrote on Monday, October 29, 2012:
Hello, I’m wondering how you would manage to run a practice with your OpenEMR being hosted on a VPS. Take into consideration the storage space you would get on a VPS - would just 20GB be enough for the OpenEMR, mySQL database, documents like lab reports, x-rays, etc?
A general question to users of OpenEMR, pls - on average how much storage space would a 2 physician practice take up, considering they use it at all levels of practice management, patient records/encounters, etc?
tmccormi wrote on Monday, October 29, 2012:
The small practices that MI-SQUARED hosts use anywhere from 10gig to 90gig depending in how many scanned documents that store and how long they have been using OpenEMR of course.
OpenEMR data itself can can grow rapidly to more than 1 Gig because of the audit log table. But otherwise the core data is rather small.
Tony
www.mi-squared.com / @tonymi2
oemr.org / @OEMR_org
juggernautsei wrote on Monday, October 29, 2012:
The practices that we host using our GoDaddy special use about the amount that Tony has said most a lot less. The bandwith use to be the thing to worry about but most hosting companies offer.
Sherwin
ww2.openmedpractice.com
suitable1 wrote on Sunday, January 27, 2013:
I’ve discovered a problem that may exist with other shared hosts in addition to mine.
Short Story: We’re getting ready to send patient statements. I did some testing using our test installation which is built under a separate domain from the production version, but it is on the same shared server. I went to show the billing person how to run statements on the production system. Failure! Fopen gets a “no permission” error. After a very, very long time I figure out that the “/tmp” directory is for all users of the server and the error is caused by trying to delete “openemr_statement.txt” created by the test user. No problem - I’ll just go to the administration/globals/miscellaneous screen and change the location of the temporary directory. Failure! The statement generation is still trying to use the “/tmp” directory. So I backtrack through the code and discover that if the PHP version is greater than 5.2 the system’s temporary directory overrides any user selection.
Has anyone else had this problem and how did you resolve it? It’s now clear to me that even if we were not using two domains for Open-EMR, the system “/tmp” directory should not be used as statement generation leaves patient data lying around until the host purges the directory. I can think of several reasonable fixes, but all require changing (and then maintaining) the code.
tmccormi wrote on Monday, January 28, 2013:
Oddly enough I just assigned this issue to one of my developers (minutes ago). The backup and and statements tools are ignoring the GLOBALS setting for the TMP directory and using the System setting. This was a reversion of a fix from a while back, it seems to be do to a change at the PHP version level, but it trickles through…
-Tony
suitable1 wrote on Monday, January 28, 2013:
I can save your developer a few minutes of time. The openemr/interface/globals.php has code at the bottom which overrides the temporary_files_dir if PHP >= 5.2.1.
There are several issues here for me:
1. There’s a significant security issue with using the system /tmp directory unless the server is dedicated to Open EMR. This is especially true in a case like mine on a shared host. Not that I liked spending quite a bit of time determining the problem, but I am glad that I realized the potential security hole before there was a lose of patient info.
2. Whoever added the override code should have done a simliar test for the administration/globals/miscellaneous screen to either remove the TMP selection or at least provide a warning.
3. Since most most of my career has been in developing/selling/using application packages, I am reluctant to start down the slipperly slope of modifying and maintaining custom code. Looks like I’ll have to for the short-term anyway, unless someone has a solution that I haven’t considered.
yehster wrote on Monday, January 28, 2013:
The MySQL Server instances on a shared hosting platform like GoDaddy are most likely not encrypted, Which means that the GoDaddy administrators could access any PHI you store which could lead to a HIPAA violation as they likely have root access.
tmccormi wrote on Monday, January 28, 2013:
Looks like it was done by Rod,
a38aba8e (sunsetsystems 2010-04-01 20:06:21 +0000 422) // Override temporary_files_dir if PHP >= 5.2.1.
60144244 (bradymiller 2009-11-17 07:37:52 +0000 423) if (version_compare(phpversion(), "5.2.1", ">=")) {
a38aba8e (sunsetsystems 2010-04-01 20:06:21 +0000 424) $GLOBALS['temporary_files_dir'] = rtrim(sys_get_temp_dir(),'/');
60144244 (bradymiller 2009-11-17 07:37:52 +0000 425) }
Rod,
Do you remember why you needed to do this?
-Tony
sunsetsystems wrote on Monday, January 28, 2013:
Hmm… looks like I rearranged some of that code but did not originate it. Looks like Brady put that in on 2009-11-16 on behalf of mi-squared. See commit 6014424.
I think what may have happened is that it pre-dated the Globals administration page and was never questioned after that. Am guessing it should be removed.
bradymiller wrote on Tuesday, January 29, 2013:
Hi,
I’d probably consider placing a global toggle above the Path to Temporary Files entitled Use PHP Temporary Files or something like that sincemaybe some users are ok with this (would default it to off, though).
Also, wasn’t there talk a few years back of using the php temp files functions for some file work:
http://php.net/manual/en/function.tmpfile.php
Anybody know if this being implemented anywhere in the codebase?
(on a quick grep, which is rather noisy, at least see it being used in CAMOS/admin.php script)
Would this also be a “concern”?
-brady
OpenEMR