Onsite or offsite patient portal

Management and Administration
#1

cverk wrote on Friday, October 21, 2011:

I seem to be having trouble wrapping my head around this.  I am using version 4.1 with all patches on windows 7 and xampp.  Does using either portal require web serving out to the internet with a fixed ip address or using dyndns.com or similar service? Does this open your production office system to huge security risks? Do you have to set up something like hhtps:  . I have to admit that the more I have read about this, the more paranoid I have gotten about the amount of personal information involved. The step from working on my intranet through my LAN behind routers, hardware and software firewalls, and antivirus software, to in some way just opening data out to the internet seems very big to me. Are there any primers out there on this, or better instructions on proper openemr security settings, or is xampp even usable for this because their site sounds pretty paranoid about it also. Even the xampp security panel is pretty confusing, and it seems phpmyadmin has its owns security issues along with xampp storing things like passwords in plain text files. I think this becomes a pretty big thing going forward particularly with some of these offices I have read about on here with over 20,000 patients.

#2

bradymiller wrote on Friday, October 21, 2011:

Hi cverk,
This is a tricky topic. I’m also pretty conservative of what to open to the web (if asked, I generally recommend using apache “client sided certificates” to secure OpenEMR if open it up on the web; this essentially passes the security over to apache and would be rather difficult, I think, to set up either of the portals with this security mechanism in place). The opinions on how to best secure OpenEMR over the internet will widely differ, but I think what is vital here is for the user to know what they are doing (ie. know how to secure OpenEMR, Apache etc.) and, if not, to consider getting help from a third party. Like the idea of having a primer/wiki page where others begin detailing their strategies to secure OpenEMR(for example, one very important thing to do is to ensure the patient documents directory is blocked via Apache, which is actually described during the OpenEMR setup script) in more detail.
-brady

#3

cverk wrote on Friday, October 21, 2011:

It seems for some reason you have to use an older xampp package 1.7.3 for openemr, but the apache folks seem to say one of the biggest security enhancements is to use the most current apache release.  Is it possible to update apache without messing up openemr?
I have managed to stay independent as a doctor by not farming stuff out of my office because I don’t understand them.  I pretty much insist that nothing goes on here I don’t understand or can’t do myself, employees included. Thats what attracted me to this project in the first place.  As I learn stuff, I am glad to share if I can help.

#4

tmccormi wrote on Friday, October 21, 2011:

Let’s be clear. 

XAMMP is a developer package. It’s intended for testing and debug.  XAMMP was never intended to be use for production or live systems.   The real, reliable and secure way to run OpenEMR on any OS including Windows, is to install and configure Apache, PHP and MySQL as separate, native apps and install OpenEMR code separately, (the Linux installer’s do that for you).

Preconfigured XAMMP is great for in-house installs that do not need external access and are behind a solid firewall or not connected to the INTERNET at all.  Anything that requires external access should be configured for security, at least HTTPS/SSL.

-Tony

#5

bradymiller wrote on Friday, October 21, 2011:

Hi,

Disagree (pleasantly) a bit with Tony here. It’s not as simple as what tool to use or not use. The main thing here is the user has a firm understanding of securing all of the parts (OpenEMR/apache/mysql/https/router/firewall/certificates etc.). Using or not using xammp is not really the issue. cverk, perhaps we should start a wiki page to begin to cover this stuff, since it sounds like you plan on taking the time to learn and go through this stuff anyways.

-brady

#6

tmccormi wrote on Friday, October 21, 2011:

This is absolutely true :_The main thing here is the user has a firm understanding of securing all of the parts OpenEMR/apache/mysql/https/router/firewall/certificates etc.). _

What I mean is that XAMMP, according to the project developers, was not intended to be used that way and therefore has some inherent security issues that are easy to overlook.  You could, of course fix them, but in my opinion, it is faster and more reliable to do it with a native installation.

On the other hand I wouldn’t recommend windows OS for any server based anything … :-)  So take that as you will.

-Tony

#7

cverk wrote on Saturday, October 22, 2011:

Sorry, just a little frustrated on being low on the learning curve, which is an unusual place for us academic allstar types. I don’t think however that I am unusual for your audience on this. I have found some literature on securing xampp and it looks to be doable. I understand the microsoft aversion, but I continue to find linux even harder to grasp.It is a reality that the vast majority of the world uses windows, and if I can find good literature and make securing it work, I will share it. I really do appreciate the input, and I hope to help intellectually push this project forward. I figured if I could get to your main installation from your portal demo site, that most of the bad guys out there could hack me.

http://www.learncomputer.com/secure-apache/

#8

bradymiller wrote on Saturday, October 22, 2011:

Hi cverk,

Again, wouldn’t really focus on things like microsoft is good or bad for security; as long as you have a form understanding of what’s involved and the weaknesses/strengths of your system.

Placed a wiki page here to begin documenting the process of hardening OpenEMR for the web. I just placed some stuff their off the top of my head just to get it started. As users, such as yourself, going through this process, the goal is to develop specific and detailed steps along the way to do it. Feel free to add/remove/modify/expand anything (for example, you may want to add a xampp and a Microsoft section). This serves two purpose:
1. Others will then be able to do it with much less effort
2.  Steps are open and can get scrutinized and optimized over time (easier for security experts to provide advice when all the steps are laid out)

Here’s the wiki page:
http://open-emr.org/wiki/index.php/Securing_OpenEMR

It’s in the Developer->Security section on the main wiki page:
http://open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Page#Security

hope this helps to get you started,
-brady

#9

bradymiller wrote on Sunday, October 23, 2011:

Hi,

Also created a set of portal instructions for both the onsite and offsite portals here on the wiki (and briefly discussed issues above along with a link to the above wiki page):
http://open-emr.org/wiki/index.php/Patient_Portal

If you’re curious, this Patient Portal howto page is in the online OpenEMR 4.1 User Guide wiki page here in the ‘Supplementary Topics’ page:
http://open-emr.org/wiki/index.php/OpenEMR_4.1_Users_Guide

Z&H Healthcare, please feel free to improve/expand these instructions to cover all the features of your offsite portal.

thanks,
-brady

#10

cverk wrote on Sunday, October 23, 2011:

As several posts have suggested, I also can’t seem to get xampp past version 1.7.3 to work, and the current version is 1.7.7 with a lot of security patches in between and going forward.  That would seem to mean that even trying to individually install and configure all of the components for a windows server won’t work, or at least I can’t seem to make it work, if you are using the most up to date versions of each component.  Since using the latest updates seems to be the number one requirement in maintaining a secure server, it seems this is currently an impass for use of windows. Meaningful use is going to require opening your server to the internet and maintaining a secure server with updated security patches.  Perhaps what Tony is trying to suggest is that it is not currently achievable under windows because openemr is incompatible with some updated component past what is used in xampp 1.7.3, and if you are going to use this to run an actual office you better start learning linux. Of course just because I can’t get it to work with up to date individual components under windows, doesn’t mean it can’t be done.  Anybody out there been able to do that, and if so, have you got any hints?

#11

cverk wrote on Monday, October 24, 2011:

I was just reading your new wiki pages and the new instruction manual.  You guys are great !

So maybe the answer to all of this for windows users is setting up a vpn type connection to the offsite portal and leaving everything else behind your firewall for office use only. Maybe they could bundle the free offsite portal with connection to a  low cost collection of lab interface,patient portal with e-mail of passwords to patients, and e-mail of patient reminders for upcoming meaningful use requirements, and possibly connection to something like the secure e-mail transfer of records into something like microsoft healthvault. Because securing the e-mail server is yet another problem. That way, it would present an incentive for developers to make the program as plug and play as possible as a conduit into a menu of offsite services, which could be presented by the various developers on a competitive basis.  Each office then would retain control of their own data and be able to send out or not send out data based on their needs. The possibilities of what could be offered through such a connection would then only be limited by imagination.  Patient care tickler files, quickbooks interface for electronic deposits, transfer of info for referrals etc.

#12

bradymiller wrote on Monday, October 24, 2011:

Hi,

Actually the VPN idea is also related to another idea that is beginning to be considered for the offsite portal. And that is the use of a technology similar to “gotomeeting” (also same technology as how microsoft logs into customers computers to fix them). So with this methodology, the offsite portal could potentially connect to the local OpenEMR instance without the security risk of opening up a web server to the public (in fact, don’t even think you’d need a static IP address).

My question is do any developers know more about this technology and if their are any open source projects that can be used to do this.

thanks,
-brady

#13

zhhealthcare wrote on Monday, October 24, 2011:

Brady
Maybe we should move this part of the discussion to another thread and this would be a very important technical addition to OpenEMR. 

I think the technology would already exist in OpenSource because webhuddle is like go to meeting and they must be using this technology. 

Thanks
Shameem

#14

zhhealthcare wrote on Monday, October 24, 2011:

I am now confused:  logmein downloads a software on to my computer and I install it.  I can then log into that computer from anywhere even if I dont have a static IP.  Gotomeeting or webhuddle has to have a meeting scheduled and initiated for anyone to log in.  So is it not a logmein kind of technology that we need?

Shameem

#15

cverk wrote on Tuesday, October 25, 2011:

Could you use something like this?

http://www.itefix.no/i2/copssh
http://www.geek-republic.com/wp-content/uploads/2009/02/securing-windows-remote-desktop-with-copssh.pdf

I am not completely sure how openemr connects to the offsite portal, but it seems like something along this line could allow directory access from an office server to an offsite server for any number of advanced functions.

#16

bradymiller wrote on Wednesday, October 26, 2011:

Hi Shameem, cverk, and everybody else,

Check out this open source multi-os project:
http://code.google.com/p/gitso/

So, I think the local OpenEMR instance can log into the offsite portal and establish a secure connection without the local OpenEMR instance needing any IP address at all. This connection could then be used:
1. for the local instance to connect to the offsite portal
2. for the offsite portal to make API calls on the local instance

As you are, I’m learning this stuff as I go, but this gitso project does look promising. I am guessing there are others out there like this.

-brady

#17

zhhealthcare wrote on Wednesday, October 26, 2011:

@cverk:  Copssh is for windows alone.  So we might have to broaden our search for the Windowphobes here … :slight_smile:

@Brady:  Gitso looks promising.  I have posted a query on their site as well.  We dont need the entire stuff of remote admin where they can see the screen and manipulate, all we need is their connection technology, right?   Keep looking: it looks really exciting.

Shameem

#18

zhhealthcare wrote on Wednesday, October 26, 2011:

Brady
I tried the forum at Gitso:  not much luck.  See the thread: http://code.google.com/p/gitso/issues/detail?id=80

Shameem

#19

zhhealthcare wrote on Wednesday, October 26, 2011:

Personally I think the guy has no imagination about what we can do with his code… :slight_smile:

Shameem

#20

yehster wrote on Thursday, October 27, 2011:

Here’s an idea to allow for an offsite portal and keep your onsite system protected on your local LAN behind your firewall etc…

Basically, the idea here is to push data from your onsite system out to the offsite system. 

The concept is to do one-way replication of data to the offsite portal.  Since data only ever moves one direction, from your onsite(master) to the offsite(slave), if the offsite server were compromised, your onsite system won’t be affected.
Since the MU requirement is that the information needs to be available within 3 days, the replication doesn’t have to happen in real-time.
So, one option to copy data would be to have a cron job that runs every night after hours on the master server which does the following.
1. MySQLDump of relevant data.
2. SFTP transfer of dump file to slave(offsite) server
3. Tell slave server to start import
Depending on bandwidth/diskspace issues, the mysqldump could be incremental (just the changes since the previous day) or full (simpler to implement)

Another idea would be to setup an SSH tunnel from the master to the MySQL port on the slave.  The master could then directly update MySQL on the slave machine. Either through MySQL dump again or by something more sophisticated, like MySQL replication.

Another good thing about this one-way scheme is that if the patient portal becomes overloaded (by users or a Denial of Service Attack) the master server shouldn’t care as all the additional workload is being directed at the offsite/slave machine.

All of the tools required for this are fairly standard and available on both Windows and Linux environments.  No need for anything “exotic” like gitso. 

P.S. although copssh is “windows only” openssh-server exists for linux and does the same thing.  SSH is a standard very useful protocol!