Being on Cloud EMR is better than being on a Web EMR, and even better than using a desktop EMR. However just because you are on the Cloud does not make you safe. This article will get your hands dirty and go a little deep and technical. However, if you stay with me all the way to the end, I promise you, that you will pick up concepts that will make you much smarter in taking the right decision for your Clinic’s technology needs.

I will not dwell on why is Cloud better than Web EMRs, or why is Web better than the desktop, which has already been covered in other articles. I will only focus on Cloud EMR v Web EMR. Why is this important to you? Let’s say you went to buy a car, and for the same price as a new Kia, you were getting a new Mercedes. Because you were unaware of the difference between a Kia and a Mercedes, you ended up buying a Kia. When you find out the difference, how happy will you be? The point is, in EMR, if you do find the difference, but it is a couple of years down the line, you would have already invested hundreds of collective hours in your Clinic for training your staff and yourself to get accustomed to the platform. You would have put lots of data in the system, which may or may not be easily ex-tractable, overall resulting in tens of thousands of dollars in write-offs. Being ignorant about technology is no longer an option. I will be gentle in the explanation and will request you, to be patient with me :). Let’s start.

 

The Cloud EMR (or clinic management system) that you use is comprised of the following components:

a. User Interface (UI)

It is the page you see in your browser. The page contains the forms you fill out, the buttons you click, and so on. It is also called the front-end part of the software. It uses a mix of technologies such as HTML5, Javascript, JQuery and CSS. The actual code that makes your UI work, can also be seen by you. All you need to do on any browser is right-click and select “Inspect” and then select “Sources”.

This code is sent to your browser from a Webserver. The webserver is a software program that runs on a computer called a Server. This server is a physical piece of hardware which is kept in the Cloud and access to this hardware is limited to the Technical Team of your EMR vendor. So the crux here is the physical Server that runs your webserver.

A Cloud EMR can use for Server various options such as Cloud Instances, Virtual Machines, Compute Instance, Cloud Services – essentially these are different names of the same thing, a Webserver on the Cloud. These are however old wines in a new bottle. These legacy Cloud technologies, allow a Developer to run his software that is not Cloud Ready, without making many changes to it. So the pitfall when your Clinic starts using such a solution is, that while you think you are on the Cloud and are benefiting from all the security apparatus associated with it, in reality, it is an illusion. It is like rock climbing thinking you have a harness, you need to wait to slip, to realize this is a free fall.

Why do I call them Legacy Cloud Technologies? Because they allow me the same advantages that a webserver not running on Cloud would offer i.e. they have the same disadvantages too. A web developer can log into that machine and make changes to the software that is running on these computers. So you could install any other piece of software other than a web server, you could log in and browse websites on such computers, and you can pretty much do anything you could do with your own home computer. That does not sound like a vetted, sanitized piece of thoroughly checked equipment. It is perhaps a bit better off than your home PC, but do you really want to be running your Clinic operations on equipment that is “slightly better off than your home PC”?

So what is the state-of-the-art option here? App Services – these are webservers running on computers on which you do not have ANY ACCESS EVER i.e. even the developers working for the EMR Vendor do not have any access to these servers. You cannot install anything on them, you cannot tinker around with them, and you cannot log in to them. It is a highly specialized piece of hardware and software combination, that allows you to do 1 thing and 1 thing only, run a webserver that builds the user interface for the users. That’s it. It is managed not by your developers but by experts of the Cloud Hosting Company (ie one of the Big 3) teams, whose sole responsibility is upkeep, maintenance and 24/7/365 health monitoring of these computers. Now we are talking about Cloud Technologies for your front-end that has no equal to your home PC. That is the Ferrari for Front-End Security, and if you are getting it for the same price as a Kia, isn’t it obvious which one to go for!

 

b. Middle-Tier

This is the code that you cannot see, which lives and executes not in the browser, but on the Server. Same logic as UI, imperative you use App Services, rather than legacy Cloud Technologies.

 

 

c. Back-End

All the data you entered in the UI needs to be stored. Data is stored in a specialized software called “Databases.” Databases have been around since the inception of computers, i.e. database technologies can be decades old. To make the transition from web-based and offline-based solutions, to migrate over to Cloud, the Big 3, also offers legacy database technologies on the Cloud. Yes, you heard me right, they have made it easy for you to save data on the Cloud using legacy, outdated database technologies. In such cases you basically get hold of a VM (Virtual Machine), to which you then log in and install whatever database you want – there are no specialized Cloud databases involved here. It’s plain old Joe, wearing new clothes today.

You need to backup your database so that in case of a disaster, data can be recovered from the backups i.e. if you backup once a day, you only lose at most 1 day of data. You need to also maintain secondary data and set up a failover so that if things go down, while you fix the issue at hand, the secondary database can serve your Clinics. This switchover is fairly simple and can be done within hours. If you have a smart database team, this can be done even in minutes.

So what is the issue here? What am I complaining about? I am complaining about the lack of progress such an EMR Vendor is making in its database technologies putting their Clinics at risk. The correct approach is to use specialized Cloud databases that are built for today. They have real-time replication and maintain secondary and tertiary copies of the database, with auto switch-over in milliseconds i.e. one-thousandth of a second, should the primary database go down. No more once-a-day backups, data in such technologies can be restored to a level of accuracy unseen before, i.e. you can restore data to a specific date and time, it’s called “point in time restore.” You do not have to accept 1 day of data loss. High Availability (HA), and DR (Disaster Recovery) are built-in, and its managed by a team of database experts working at the Big 3 (Amazon Web Services, Google Cloud, Microsoft Azure), backed by the EMR Vendor’s own IT team. Now you are talking about a team of qualified dedicated people working together to offer you the best of what database technology has to offer, and not an individual developer trying to figure it out and make it work for you.

 

So why will any company in their right mind not switch over to the cutting-edge options in Cloud Technologies? For economic reasons. It can be very expensive to re-design a working solution and make it work using newer technologies. It is much easier to instead opt for a name brand Cloud Hosting company that allows you to use your same old legacy technologies and make your solution run on the Cloud, letting such a company market to you on their website that “come use our Cloud EMR and access your data anytime, anywhere.” Wouldn’t such slapstick, quick-fix jobs unravel eventually, surely you cannot patchwork your way through to save a building with weak foundations? You are right one cannot do this, then why do you want to hang around to find out what happens to such a building eventually?

 

 

---