OpenEMR Complete Installation Tutorial

From OpenEMR Project Wiki
Revision as of 10:33, 26 January 2018 by Bradymiller (talk | contribs)

Overview

Hello All,

About three weeks ago (posted this on 1/26/18), I decided that OpenEMR was for me. I've had two proprietary EHRs since I started practice, and I was tired of being at the mercy of my EHR overlords. And paying for a suboptimal product.

Here is what I wanted:

  • OpenEMR in my office
  • An easy, reliable way to backup the data (which is what had scared me to not do this years ago)
  • A secure way to remotely access the EMR from anywhere (which also had scared me away from DIY)

Here were my prior conditions:

  • I'm a solo physician with a practice that currently hasn't been busy. So I had time to devote to this.
  • Because it's just me, only I needed to access the EMR remotely. So my setup didn't have to be overly complicated.
  • I'm comfortable in the EHR space, as I haven't been on paper since day 1 of my practice.
  • I know how to connect together my own local network.
  • I have a working knowledge of Windows.
  • I had zero knowledge of Linux. Not a whiff.
  • In that sense, I'm an idiot.

The following is how I managed to make this happen (thus far!), under the pre-conditions above. It's taken me about three weeks of obsessive time, combing through the wiki and the forum and all the offshoots, to get to where I'm at so far. I apologize beforehand for the length of this post. But my hope is that if you're like me above, this post will serve as a one-stop-shop and shorten the learning curve for you significantly. I'll drop references throughout this post that go back to the sources I used.

1. Install on Windows or Linux?

This became the first big question. I knew nothing about Linux, so I first installed using the Windows instructions. It worked on my local computer, and it's worked well for many others who have posted in the forum. But the more I read, the more I felt I should go with Linux. This thread was influential: https://community.open-emr.org/t/switching-my-server-to-ubuntu/1778.

I was getting more uncomfortable with Windows security, and OpenEMR developers like @brady.miller seemed to be leaning more toward Linux. So Linux it became. I'd say it's worth it in the end, because you'll find a lot of the configuring based on instructions you read here and on Google searches is Linux-based. And it becomes relatively straightforward...once you know how to move around in Linux. Which leads to the next question:

2. GUI or command line?

In various posts you'll start reading about writing command lines like sudo vi and apt-get install and echo this and that. WTF?! I'm a point-and-click, cut-and-paste guy. I didn't even fully realize (until I developed a basic understanding of Linux) that when we point and click on Windows, we're actually using graphical shortcuts to execute commands behind the GUI curtain to the computer. Idiot, remember?

Now, you could mimic your Windows experience and get a GUI-based Linux operating system (Linux Mint seems to be judged the easiest). But I went the masochistic route and chose a straight-up server, with no GUI! Why? Because it seems to be faster when the computer isn't bogged down with a GUI. It's more secure (not as many potentially open doors to get in). And perhaps most importantly, with the command line you can actually directly tell the system what to do! And you can write scripts (i.e., copy scripts other good people already wrote) that automate everyday tasks. Once I got that, a light bulb went off. So I forced myself to stick with a command line interface. Yes, Windows has one too...but to use that, are you kidding me?

To get comfortable with the command line though, you have to know how to move around in Linux. You have to get comfortable finding files, making directories, moving and copying things, downloading and installing things, editing files, etc. I was stupid and tried to learn this on the fly. Then I took this free Linux Foundation e-course recommended in the forum: https://www.edx.org/course/introduction-linux-linuxfoundationx-lfs101x-1.

I should have done this first. If you go straight through, it should take you about two, maybe three solid days. It gets a little tough at the end -- but honestly you don't really need to know how to write scripts, for our current purposes. You just need to know, for example, that almost everything in Linux is basically a file of text that you can actually read. And then edit based on instructions you find on the wiki/forum or in a Google search, written by people much more adept than you or me. This course will bring you up to that comfort level, with ZERO starting knowledge of Linux. It doesn't seem to be searchable, but once you're done you can then search online for whatever you need to know and follow what people are saying. So if you're going commando, **do this first!** I can't emphasize that enough.

3. Stand-alone operating system or virtual machine?

You could install the Linux operating system (freely, by the way, as it's also open-source) on a computer with nothing else on it, or as a dual-boot with another existing operating system. Both options scared me. So I went with a virtual machine (VM). A VM is software that sits on top of your existing operating system, essentially shares your computer, and launches a different operating system. Your computer with its existing operating system is the host, and the VM is the guest. What this allows you to do is play around with Linux and build and break things without worrying about bricking your computer. I also liked the idea of having one extra layer between the outside world and my local network (more on this later). Once you've gotten it to your liking, you can even export the whole VM and import it to another computer, thus serving as a backup and method of quick deployment. Pretty cool. So I went with the option of setting up a Linux VM on my existing Windows host computer.

4. Installing Ubuntu server on the VM

You install the VM first. I used VirtualBox; the other one is VMWare, but I can't comment directly on how to use that. Download the Windows version of VirtualBox here, and also download and install the Extension Pack: https://www.virtualbox.org/wiki/Downloads. If you have a 64-bit operating system and you only see 32-bit options when you're creating a new VM, you have to enable virtualization technology in the BIOS (see this article on how: https://docs-old.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/sect-Virtualization-Troubleshooting-Enabling_Intel_VT_and_AMD_V_virtualization_hardware_extensions_in_BIOS.html).

There are different flavors of Linux out there; I chose Ubuntu. It seems to be the most popular. Download the server version here: https://www.ubuntu.com/download/server. 16.04 is the version with long-term support, which is what I used. Remember, the server version has no GUI. I encourage you to take the plunge, but if you just can't do it then you would just fall back to Ubuntu Desktop or Mint (which is based on Ubuntu). Everything I say below is based on the command line interface.

Install VirtualBox, then hit New. Choose Ubuntu, and then pick what size RAM and hard drive you want (it's all virtual, there's no actual partitions). I originally chose 2 GB and 20 GB, respectively, but I think people have chosen way less and been fine. (It is a quite a process to change the hard drive size later on if you need to, but I'll save you the gory details here on how. Just know that it can be done.)

This builds the skeleton for the VM, but now you have to install the Ubuntu operating system itself onto the VM.

Under the heading Storage it'll say [Optical Drive] Empty. Click on that, and choose the .iso file that you downloaded from Ubuntu. Then start the machine. Go through all the prompts. The first password you choose will be the main one to execute commands at the root level, so make it strong. I chose yes to encrypt the home directory, used the entire hard disk for partitioning (others partition and independently encrypt as they see fit), left http proxy blank, chose yes to install security updates automatically, selected the LAMP server and OpenSSH server (standard system utilities already checked), left MySQL root password blank (you'll set it later), and chose yes on the question about the grub bootloader. When all is said and done, you should have Ubuntu up and running on your VM.

What you've just installed (among other things) is a LAMP server. L is for Linux, A for Apache, M for MySQL, P for PHP. OpenEMR is all browser-based, meaning you need a web server to run an OpenEMR website. That's what Apache does. MySQL is your website's database. PHP is the scripting language for the website (what Wordpress is also built from).

Two asides: 1) on the Download page at open-emr.org are instructions to install an OpenEMR "appliance," which is compatible with VirtualBox and VMWare. I got confused and thought this was what I was supposed to follow if I was going to use a VM. Wrong! The appliance is a a pre-configured install designed for quick deployment which works through a modular platform called Docker (thanks for explaining, @APerez). I couldn't find any of the files/folders that call for later editing with this and got lost. You'll be using the Linux OpenEMR installation itself, NOT THIS APPLIANCE. 2) If you encrypt your home directory and ever need to recover it, you'll need your mount passphrase. I think it comes up during the Ubuntu GUI install, but Mint doesn't show it (see this thread: https://community.open-emr.org/t/word-to-the-wise-re-encrypted-home-directory-in-linux-mint/2896). And I haven't seen it come up in the Ubuntu server install either. So before you go any further, log in with your username and main password, then run this command: ecryptfs-unwrap-passphrase. Type in your password again, and you should see your long mount passphrase. Write it down somewhere safe before you move on.

5. Installing OpenEMR on Ubuntu

You'll want to download the OpenEMR package from here: http://www.open-emr.org/wiki/index.php/OpenEMR_5.0.0_Ubuntu-Debian_Package_Installation_with_PHP7. Under the heading, Command Line Ubuntu/Mint Installation, type in the commands in red. I always got the error that it didn't install fully, so type in that extra command mentioned in the instructions. It should proceed on. Eventually it should ask you to create a MySQL root password, so be sure to set it here. It should finally say OpenEMR was successfully installed and configured. If you browse on your browser to http://localhost/openemr right now as the instructions state, it won't work. That's because port 80 isn't open by default on your VM. Go back to VirtualBox and find Settings and Network. It'll be on NAT. Hit Advanced, then Port Forwarding. Make a new rule that opens up port 80 on the host and the guest. Port 80 is the default port for http (unsecured) webpages. I'll talk about networking/port forwarding in more detail later, but this is just to make sure OpenEMR launches, for now. It should work now.

6. Installing OpenEMR Patch

The latest patch is here: http://www.open-emr.org/wiki/index.php/OpenEMR_Patches. Back at the command line type wget open-emr.org/patch/5-0-0-Patch-7.zip. That'll download the file. Now you need to move it to the proper directory. The command pwd will tell you where you're currently at. You're probably still in your home directory, which has the path /home/hostname (whatever you set on the Ubuntu install). The path for the openemr web directory referenced by the patch instructions is /var/www/openemr. I set my hostname as openemr, so my command to move the file would be sudo mv /home/openemr/5-0-0-Patch-7.zip /var/www/openemr. If you move yourself to the destination directory (cd /var/www/openemr) and type ls, you should now see the patch file there. Now you need to unzip it. You might need to first install the unzip program (sudo apt install unzip). Now type sudo unzip 5-0-0-Patch-7.zip. Confirm to copy over all the files. Done.

A little cleanup time: as instructed, remove the setup.php file (sudo rm /var/www/openemr/setup.php) and the open-flash-chart.swf file (sudo rm /var/www/openemr/library/openflashchart/open-flash-chart.swf). Also remove the patch zip file and the original OpenEMR installation file, which is probably still sitting in your home directory.

7. Securing OpenEMR

First, start with this page on the wiki: http://www.open-emr.org/wiki/index.php/Securing_OpenEMR. Just start going down the list. Under heading OpenEMR, we've already removed the setup.php file. Now remove the other files mentioned. The command to remove an entire directory is sudo rm -r and then name of the directory (but you should know that by now!). I couldn't find the file sl_convert.php, and you would not want to remove the phpmyadmin directory yet if you're needing to use this to import old patient data (see below). Also, keep the restore file in the contrib/util directory (see Backing Up section below).

Let's skip Network and Apache for now. Under MySQL, you should have already set the root password. Under PHP, hit the link on settings recommendations. You'll be editing the php.ini file, which is at /etc/php/7.0/apache2/php.ini. Open this file with an editor (I learned the basics of vi from the e-course, but nano is easier) and edit/save. Most of the settings are already set to the recommendations. Remember to restart the Apache server (sudo service apache2 restart) to apply the new settings. XAMPP for Windows isn't applicable for us.

Back to Apache. I found that much of the hardening of Apache is already done for us in the Ubuntu install. For example, direct access to the documents, era, and edi directories has already been turned off. I won't comment on the patient portal, because I haven't set that up. I did do one other thing, which is to erase the Apache welcome page. You get to this by just browsing for localhost (not localhost/openemr). Why announce to someone what kind of Apache you have? To modify this page, first backup the page by renaming it, if you ever want it back (sudo mv /var/www/html/index.html /var/www/html/indexbackup.html). Then do sudo vi /var/www/html/index.html (or whatever editor you've gotten comfortable with besides vi) and type in Hello World. That's all someone will see.

Now, we currently have an http:// website, which is unencrypted. We want an https:// site, which is encrypted. And I wanted to force all access through https alone. To do this, we need to create a self-signed SSL certificate on Apache. I found this article, linked from the Securing page on the wiki, useful: https://www.digitalocean.com/community/tutorials/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-14-04. Look this over; it's well-written. But I then found that you can create the certificates and keys through OpenEMR itself (beginning with 5.0.0?). Just go to the Adminstration menu, then Other, then Certificates. We'll focus on the first half of this for now. Fill out the information in the first box (I just used openemr for the hostname) and hit Download Certificates. You'll download an ssl.zip file. Unzip that file in Windows. There will be five files: admin.p12, CertificateAuthority.crt, CertificateAuthority.key, Server.crt, and Server.key. The instructions on OpenEMR call for adding these new certificates to the Apache configuration file. But how do we get them over there? We can't just cut and paste!

We have to share a folder between our Windows host and the Linux guest. To do this, we have to first install VirtualBox Guest Additions. This article explains how to do it without the GUI: https://www.techrepublic.com/article/how-to-install-virtualbox-guest-additions-on-a-gui-less-ubuntu-server-host/.

Follow these instructions to the letter. Once Guest Additions is installed, create a folder on your Windows desktop that will become the folder shared between the host and Linux guest. Move all your certificates and keys to this folder (you don't need to move admin.p12). Then go to the VirtualBox main screen and click on Shared Folders. Click the Add icon and set the path to your folder on the desktop. Give it a name. You can leave the other boxes unchecked. Now go back to your Linux command line and create a directory named host in your home directory (sudo mkdir /home/host). You will now mount the shared folder to this host directory with the command sudo mount -t vboxsf -o uid=$UID,gid=$(id -g) share /home/host (replace share with the name you gave the folder in VirtualBox). When you open the host folder, you should now see your certificates and keys. (Aside: with Guest Additions installed, you're supposed to be able to copy and paste from the host to the guest and vice versa by setting Shared Clipboard to Bidirectional, but I couldn't get it to work.)

Now we have to configure Apache. Click back to the DigitalOcean article above. Beginning with Step One, go right down their steps. The only part you'll skip is the command for making the key and certificate -- you already did that through OpenEMR. When you make the /etc/apache2/ssl directory, move the keys and certificates you had in /home/host (the shared folder) to this new directory. Therefore, the paths you will use when you edit the default-ssl.conf file will be /etc/apache2/ssl/Server.crt and /etc/apache2/Server.key for SSLCertificateFile and SSLCertificateKeyFile, respectively (Server.crt and Server.key were the names created by OpenEMR). When you finish Step Four, the https site won't be accessible yet. You have to go back to your VirtualBox, go to Network/Advanced/Port Forwarding, and create another rule that opens port 443 (the default port for https) on the host and guest. Now when you call up https://localhost/openemr, it will work. What you've just created is an encrypted site. Your browser will still say something like "not secure," because the SSL certificate you created was self-signed by you and not some third party. But the purpose of this wasn't to validate your OpenEMR website to the public at large, it was just to encrypt it. Mission accomplished.

This has all been on the server side. Now we go to the client side. If I'm going to access the site remotely, I didn't want anyone else to have access except if I granted it. To understand how to go about this, this thread was influential, specifically the exchanges in the middle among cluge, @sunsetsystems, and @brady.miller: https://community.open-emr.org/t/security-vulnerabilities/5728/7. They were debating between setting up a VPN tunnel between the client and the server, versus setting up client-side SSL certificates. As I understand it, with a VPN it's essentially as if the client, securely connected, is on the local network itself. So the client can do anything you'd be able to do on the local network. That seemed like overkill for my purposes -- I just wanted secure remote access to the web server. A client SSL certificate validates the client to the server. Without it, the client wouldn't even be able to get to the login screen. That would work for me. And because I have a small practice, cluge's concern of having to deal with a bunch of keys wouldn't apply.

The cool thing I realized about client-side SSL certificates is, OpenEMR has made it easy to set up and deploy them. We're already halfway home to this. Remember the five files generated by OpenEMR above? We've used two of them; we'll use the last three now. Reopen the /etc/apache2/sites-available/default-ssl.conf file with your preferred editor. Edit the SSLCACertificateFile to point to /etc/apache2/ssl/CertificateAuthority.crt (the line is already there, just take the hashtag off and change the path). Take the hashtags off SSLVerifyClient require and SSLVerifyDepth, change SSLVerifyDepth to 2, and make sure SSL Options is set to +StdEnvVars (should already be). This is all per instructions on OpenEMR's Administration/Other/Certificates menu. The next section there is about configuring OpenEMR to use client-side SSL certificates, but you don't have to go directly into the globals.php file like it says. Just go to Adminstration/Globals/Security -- there it is! Check the box to enable client SSL, set the path to CA certificate file as /etc/apache2/ssl/CertificateAuthority.crt, and set the path to CA key file to /etc/apache2/ssl/CertificateAuthority.key. Now if you try to log in to the site via https, you should get a rejection that says you don't have a certificate. Ah, but you do! It's the admin.p12 file. Figure out where in your browser you need to import it (in Chrome it's in Settings/Advanced/Privacy and Security/Manage certificates. Once that's done, you'll be able to select your certificate when you first browse to your https site, and you're in.

You'll need to create a client-side SSL certificate for every machine you'll launch the https site on. To do that, just go back to Adminstration/Other/Certificates and go to the very bottom. You can generate more .p12 certificates there.

Almost done for this part -- but the http site is still up. To not have it accessible, just edit the /etc/apache2/ports.conf file and hashtag the line, Listen 80 (this turns it into a comment). Now the server is no longer listening to the default port for http. We can take other steps too, as discussed in a bit.

8. Remotely Accessing OpenEMR

We can now securely access OpenEMR, and if we don't have an administrator-assigned client SSL certificate installed on our browser, we can't access it at all through https. If we're in-house on the host computer itself, the address is https://localhost/openemr. If we're not on the host computer but on our local network, localhost is just replaced by the IP address of the host computer (something like 192.168.x.x, depending on your router configuration). But what about remotely accessing the site OUTSIDE our local network? This has everything to do with IP addresses and port forwarding.

Port forwarding had always been confusing to me. How do I access MY 192.168.x.x when everybody else has similar tables? Allow me to demystify it. Imagine a long cylinder with two open ends, between wherever you're at remotely and your local computer. Now fragment the cylinder, so that now you have smaller cylinders each with two open ends. Each cylinder represents an IP address. The ends are the ports. For each cylinder, one end points outside (external) and the other points inside (internal). And when you define all the IP addresses and line up all the ports, you recreate the tunnel between you and your local server.

If you're on your local network, find out the IP address your ISP assigned to you now, by just Googling what is my ip. Now find out the address your router assigned your local computer (in Windows 10, go to Network and Sharing Center, click on your connection, and hit Details: you'll find your IPv4 address). Then go into your router configuration and use its Port Forwarding to open port 443 to your local computer's IP address. You could do this, for example, by creating a rule there that sets the external port as 443, the internal port as 443, and the internal address as your computer's IP address. The internal port here lines up with the host port set before on your VM. The external port is part of the address you browse remotely. So say your ISP-assigned IP address is 66.23.17.16 (I just picked these at random). You could then access OpenEMR by browsing for https://66.23.17.16:443/openemr. You technically don't need to add 443 there because that's the default for https. But I'd like you to get this point, because you can change all these port numbers. Say you want to address OpenEMR with https://63.23.17.16:4430/openemr -- just change the external port setting in your router rule to 4430. If you want to change the internal port in your router to 4431, you would also change the host port in your VM to 4431. If you change the guest port in the VM (the last port in the chain), you'll need to edit /etc/apache2/ports.conf in the server to listen to that new number, plus also edit /etc/apache2/sites-available/default-ssl.conf to reflect the new number (and then restart Apache and perhaps reboot the VM). This may all be overkill, but I changed out my ports from 443, because of rogues who "port scan" to see what ports are open. The default ones may be more frequent targets, so I figured I should add one more layer of defense. What I also like about the VM setup with the Network on NAT is that there's one more area of port control. VirtualBox, not your router, assigns the final IP address to the VM itself (127.0.0.1, i.e., localhost). There's an option to set the network to Bridged Adapter, which makes the overall configuration simpler because your router now assigns your VM inside the host an IP address, just like it does for any other workstation on your network. But now your VM can be seen on your local network. Call me paranoid, but I like the extra distance with NAT, and the flexibility. E.g., another way to disable http access to OpenEMR: just erase the rule opening port 80 in VirtualBox.

A couple of wildcards: the IP addresses assigned by the ISP to your office and by your router to the host computer can change, which would break the tunnel if you don't keep track of how they changed. If your ISP has given you a static IP address (and charged you more for it), then this issue is irrelevant to you. If you're a cheapskate like me, than your ISP is giving you dynamic IP addresses that change periodically. The solution to this is to sign up with a dynamic DNS provider that tracks your public IP address as it changes and links it to a fixed domain name. I'm using Duck DNS because it's simple, but there are several other free ones to choose from. You then have to set your router to connect with the dynamic DNS provider (most routers set this similarly). Once this is done, the final address you browse to from the outside might look like https://xxxx.duckdns.org:port/openemr. The other wildcard is your router changing the private IP address of your local host. To fix that, you can either set your host to have a static IP address (Network and Sharing Center/Connections/Properties/highlight Internet Protocol Version 4/Properties/switch off from obtaining IP address automatically and set static address), or figure out how to have your router set a long DHCP lease for that computer that keeps the assigned IP address from changing.

Remember, if you decide to change your ports from the default convention of 443, you will always need to add :port near the end of your url, before /openemr (even locally). Because that's the only port you've opened.

You may decide later on to open up port 22 as well, which is the conventional port for ssh connections. An ssh connection will allow you to connect directly to the VM remotely, in an encrypted tunnel. You can then access the command line interface. I haven't done this yet myself, but it's possible and preferred by many.

9. Backing up and Restoring OpenEMR

For Linux users there's a number of different options on the wiki: http://www.open-emr.org/wiki/index.php/OpenEMR_Backup_Tools. You'll need to choose what's most appropriate for you, while keeping in mind all the caveats the wiki relates. The easiest option may be to use the built-in backup option in OpenEMR and follow the Backing Up Using Built In Tools to restore (this is where that restore file in /var/www/openemr/contrib/util comes into play). But there is a thread that discusses how backing up via the browser becomes increasingly unreliable as the file sizes grow: https://community.open-emr.org/t/backups-are-not-downloading/432. Is this still an issue? I don't know.

In any case, I wanted my backup system automated, daily, and with an off-site component. So I chose the first option on the wiki, the script fullbackup4.sh. This script creates an encrypted backup of the MySQL database and the /var/www/openemr directory, and stores it locally and on DVD. I can then just take the DVD off-site. And all this can be automated. But I had to dig much more to get it to work.

The preparation instructions before the script can function are all in an old OpenEMR 3.0.1 Appliance Manual by @brady.miller that I found in an obscure location here: http://www.open-emr.org/wiki/index.php/SSL_Installation_Howtos (click the Ubuntu Install link). I actually have found this pdf manual quite useful to understanding all the moving parts of OpenEMR, even though the content is outdated and not all applicable currently. The backup instructions are found starting on page 42. They explain how to get the package that burns the DVD (growisofs) and how to generate the public-private key combination that encrypts the backups, using gpg. Adapt these instructions to current (e.g., you're going to wget fullbackup4_sh.zip from the above wiki page and then unzip it, not wget http://bradymd.com/fullbackup3.sh). As the instructions say, remember to backup the /home/openemr/.gnupg to somewhere safe (it's a hidden folder, so ls -a), and never forget your passphrase. Also, I used this to generate enough entropy to finish making the keys: https://www.howtoforge.com/helping-the-random-number-generator-to-gain-enough-entropy-with-rng-tools-debian-lenny (I know this all sounds weird, but you'll understand when you get there). As the instructions state, you have to change the DVDDEVICE pathname. Find out the pathname as follows: cd /dev, then ls -l dvd. My symlink labeled dvd (and also another labeled cdrom) was connected to the pathname sr0. So I changed the pathname in the script to /dev/sr0. To get the VM to actually connect to the DVD writer, you go to the Device menu on the VM, then Optical Drives, then choose the host drive for the DVD writer. One more thing: go to Settings and Storage, find your host optical drive, and check the box that says Passthrough. If you don't check that stupid little box, it won't work. Lastly, the script fails to mysqldump the database when you first run it. You'll get an error 1045, because it's looking for the MySQL root password to authenticate the dump. Obviously if this is all going to be automated, you can't put in a password. It would also be a security risk to have the root password plainly in the script. The solution is a utility call mysql_config_editor. This article explains it best: https://opensourcedbms.com/dbms/passwordless-authentication-using-mysql_config_editor-with-mysql-5-6/. This is the command you want to type: mysql_config_editor set --login-path=testbed1 --host=localhost --user=root --password. Change testbed1 to whatever you want. Once you run this, you'll be asked for the password; this will be your MySQL root password. Now you can edit the beginning of the mysqldump line in fullbackup4.sh to this: mysqldump --login-path=testbed1 (or whatever you chose) --opt openemr... So now you have an encrypted way of automatically sticking your root password in that line. Run it ( sudo /root/fullbackup4.sh).

Voila! Everything should work. Should! As the pdf states, sudo crontab -e and set this all to run whenever you want, with the caveat about midnight in mind.

The other caveat that the wiki makes clear is that a backup is useless if you haven't verified the restore process. You need to know how to access the files on your DVD and in the local directory on Ubuntu -- and how to restore them! As for the DVD, you can verify the files are there by just opening the DVD in Windows. But to access the files in Ubuntu, you need to mount the DVD. Here's how to do it: https://www.lifewire.com/how-to-mount-dvds-and-cd-roms-using-ubuntu-4075034. You should now be able to see the files in Ubuntu. Next, study the script so you can know where these backup files are also going in the local directory (/tmp/openemr_backup). Go find them so you can practice how to restore them. There will be two files in a given uniquely dated folder: www_openemr_backup.pgp and mysql_openemr_bckup.pgp. The first file is a tar (i.e., archived) and then gpg encrypted version of your entire /var/www/openemr directory. The second file is a MySQL dump of the database openemr and then gpg encrypted (no tar). To restore, you have the reverse the process: decrypt the file, then untar it (in the case of the web directory). The command to decrypt is sudo gpg -o outputfilename -d www.openemr_backup.pgp (-d mysql_openemr-bckup.pgp for the database). You have to execute this command in the user account, NOT in the root account, because your keys are user-specific. I don't get all this completely, but don't waste your time like I did. Move the backup files you want to restore into /home/openemr, then run the above command. If it asks for the passphrase, you'll know it's working. For the web directory, you then have to untar the output file (tar xf outputfilename). That brings out the openemr web directory, which you can then replace the old directory with. For the MySQL database, there's nothing to untar. To restore the database: mysql -h localhost -p openemr < outputfilename. Your dumpfile is feeding back into mysql. Here is a nice reference for importing your MySQL dumpfile into your database: https://www.cyberciti.biz/faq/import-mysql-dumpfile-sql-datafile-into-my-database/.

When you're running a VM, you can also export the entire appliance! A file will be created, which you can then use later to import into a fresh VM. I'm not sure how practical this from an everyday standpoint, but it does allow you to recreate all your edits and settings from the old VM -- essentially mirroring the entire thing.

10. Importing Patient Data into OpenEMR

Finally, you may be migrating from another EMR and want to import patient demographic data into OpenEMR. Everyone's situation is likely to be different. My existing EMR allowed me to export patient demographic data to a csv file. How to get this into OpenEMR? I used this thread as a reference: https://community.open-emr.org/t/import-patient-list/3223. What this thread doesn't effectively convey is how you may pull your hair out trying to match all the columns in the data table. They have to match EXACTLY. It will take patience, it may take hours, but it's better than having to manually enter thousands of patients into OpenEMR.

As the thread states, make a few new dummy patients and fill out as much demographic information as you can. You want to get a sense of what the output looks like when you export this test data. To do this, you will go in OpenEMR to Administration/Other/Database. This gives you access to phpMyAdmin. In the Filter by name or regex small field on the left, type in patient. You want to then click on the patient_data table. The Browse tab will show all the existing data you just put in. Choose the Export tab to export this data in csv format. Then open that into a spreadsheet. I first used Excel, which I'm no expert at. Excel seems to do funky hidden formatting things, like truncating columns on the end that look empty. This caused me hours of pain. I kept getting errors on the later import, and I ended up using Notepad++ to figure out what was going on. OpenOffice Calc didn't seem to do as much hidden reformatting as Excel. Use the dummy patient template to then get your old-EMR patient csv data to look the same. The birthdate has to be in yyyy/mm/dd format to import correctly. You may be counting dozens of tiny commas in Notepad++. But you'll get it. Then you'll go to the Import tab and choose your hopefully close-to-perfect reformatted csv file to get all your patient data in. If it works perfectly, you'll get a nice green successful bar. Fat chance. You won't the first time...you'll get a red error bar. You can use the error notice provided to try to decipher where the problem is. It will actually import patients all the way up to the row with the error. To try again, go to the Operations tab and hit Empty the table (TRUNCATE). DO NOT hit Delete the table (DROP), else you'll be having to learn MySQL to restore that patient_data table (or starting all over again). At some point, I felt comfortable enough on Import to check the option that says Do not abort on INSERT error. Then it sailed on through. Then again, what I was importing wasn't complicated -- just names, dates of birth, addresses, phone numbers, and emails. Your results may vary.

The End...of the Beginning

Whew! That's it. Again, forgive me for the length of this. To be sure, this is as much for me to remember everything I've done, as it is for you. But I continue to be amazed at the talent, hard work, and generosity of this community. Please accept this post as an initial token of my gratitude for how awesome this community is. With their help, I've gotten this far. And if anybody in the community finds an error in what I've said here, let us know.

I hope this post helps. When you're done, congratulate yourself on charting this new path. We've been through years and years of medical school, residency/fellowship, and practice. If you got through all that, you got this. You'll be free at last of EMR tyranny. And when everything is up and running, it will feel so good.

Safe travels, Venu

Retrieved from "https://www.open-emr.org/wiki/index.php?title=OpenEMR_Complete_Installation_Tutorial&oldid=26729"