96 percent of healthcare organizations are using or considering using the cloud, according to the Dell Global Technology Adoption Index. In fact, healthcare organizations that are already using the healthcare cloud 2015 has reduced their IT costs by an average of 20 percent annually. So what’s in store for the healthcare cloud in 2015?
We sat down with Stephen Piazza, Chief Technology Officer at Invidasys to learn more about how the cloud is reshaping healthcare IT in 2015.
Q.
What are three trends reshaping the cloud in health IT in 2015?
1) Cost
Cost is a very big consideration when we are talking cloud because, as we all know, most Healthcare IT systems are expensive, the software is expensive, the number of instances of servers that we need to purchase gets prohibitively expensive. As we talk about moving into the cloud we are moving into a completely foreign pricing model to most healthcare IT shops. They are used to buying servers and storage. But, with the cloud, we are moving into a fully virtualized environment that is not on-premise and the organization is getting charged for: every service that they use, every piece of storage, every piece of bandwidth that they use, every user, etc. So the way that we control cost in the cloud is with multi-tenancy.
With multi-tenancy, for instance, we create a single instance of a database server and we serve all of my clients / tenants from that one single database server. The application has to be architected to be secure within a multi-tenant environment. But as we craft our applications to be a multi-tenant applications, we can share more and more pieces of the infrastructure puzzle. With a legacy/turnkey application, we might be able to share the database but we can’t share the application servers and we can’t share the front-end user experience. As we morph our application to be truly multi-tenant, now we can share the database servers and the application servers, and potentially the user experience. The user experience layer on a legacy app might be a windows forms app like outlook or word where we had a terminal server out in the cloud to be able to host that user experience. When we move into the cloud we really need our user experience to be web-based because that puts the responsibility for rendering onto the client so we don’t need another layer of servers out in the cloud to host that. So web-based, multi-tenant, shared instances is how we control costs in the cloud.
The other thing that really helps out with cost-containment in the cloud is a difference in the way we think about provisioning a tenant’s environment. If we were in a traditional IT world, we would figure out the server requirements that we would need to run the environment and it would probably be tipped towards the maximum utilization. We could have up to 50 users, we are going to need this exact box size with this much disk on it, and it must handle growth because you can’t just upgrade it every day or every week to handle additional volume. But this is not true in the cloud. In the cloud we can ask: “What is my immediate demand?” And we can provision our instances to that size. And if we find that we have higher demand tomorrow, we can add memory, we can add processing power. If we are architected correctly, we can just add additional instances as demand increases. Over just a day we can throw additional resources at the environment and then remove resources as demand wanes off. So now the amount of services, the amount of bandwidth/ processing power that we are paying for can shift day to day, hour to hour, week to week, to mirror what is actually happening in the environment rather than having to size for maximum utilization. In summary, we can save a lot of money by dynamically shrinking and growing the size of the environment that we have in the cloud.
2) Customization
Customization is definitely one of those things that you look for with a cloud deployment and you might think that it is not customizable. Because what did we do in the traditional IT environment? We would branch off of a client’s environment and modify their UI (User Interface) and they would get their own special install. We don’t want to do that in the cloud. Because we want to be able to share these instances between multiple tenants and if we are customizing for one tenant it would seem that we are breaking the application for everybody else. But this is not the case. Our software now has to get more intelligent. The customizations are different in the cloud. They aren’t compiled in, they are data-driven. So the software knows that there are multiple tenants. We have modeled the tenant-model in our configuration database. The customizations are modeled in the configuration database, so when Tenant A comes in, we retrieve the configuration from our database and it says tenant A gets this color-scheme, Tenant A can see these fields, but Tenant B has a little bit differently tweaked customization experience. So it is all data-driven. Rather than “compile time”. That’s how we handle customizations in the cloud. And legitimately everything has been moving that way even within in-house turnkey solutions because it’s a pain, from a development standpoint, to manage 20 branches of code because they are all customized; because now I cannot adequately test, it is harder to deploy, and we have unique installation requirements per client. It’s a nightmare. The cloud is a data-driven configuration versus having a different binary for Client A vs Client B.
3) Collaboration
Not sure if this is really particular to cloud or just in general. We have some really great services that are coming out, the Googles of the world, the Microsofts of the world, they are all-around enabling your applications for collaboration. So if we look at something like Microsoft Office365 we see that collaboration is built throughout the entire stack. Microsoft has been making a big push with its partners, to integrate the Office365 experience into their applications. So one of the things that we will be doing at Invidays, is enabling that layer. It starts with the Lync component but, we can integrate the entire user account experience within our application so that Word for Office 365 is supported directly in our application. For instance, a user can pull up a word online document, they could have real-time collaboration on a web page and pull in additional CSRs that are looking at particular data on the screen for an online chat. That can all happen with integration within those Office365 tools, which is easy to do now because they are always available in the cloud. You just pay for the service. Which is very low-cost. So the trend of pa- by-month, pay-based-on-number-of-users that you have, it’s an all inclusive service. So the company pays $18 per user per month and they get everything they need for this cloud of software. And that’s where the pricing model is turning, even for Healthcare IT. Pay-by-month.
Q.
What are some of the key risks and challenges providers will faced in 2015 and beyond?
The biggest problem that providers have had over the last 10 years is that the volume of IT software choices is huge. There are thousands of vendors out there. And a lot of them are small software organizations and their products don’t communicate very well to the managed care systems. Example: Providers want to submit claims back to XYZ Health Plan. Today, the industry can do that with 837’s but trying to actually get that communication layer to work can be an extreme pain. So we have seen a lots of intermediary service providers, or clearing houses, come out to service the providers. Traditionally, they are called clearing houses, but they do a lot more than that for the provider community and the health plans. For Health Plans they aggregate all providers into a single end-point so that now we take a file from the clearing house and it has the 837s from all of the providers, not just one, so we are not having to create a trading partner relationship point-to-point. But what it does for the providers is that the clearing house handles taking in that claim and normalizing it and making sure that the Health Plan is able to read it and deal with it. Because if you have worked with EDI transactions, it is not so much open to interpretation but to with what data goes where (the data mapping)? For instance, do we have to put this field into this location or can we leave it out? That’s all specified by the Trading Partner Relationship and the clearing houses broker that so that the provider does not have to deal with that complexity. But where it needs to go is more of a point-to-point connection between the provider and the health plan. So that the health plan can truly communicate with the providers more than: “I received your claim. I am going to pay it. Here’s your money.”
The Health Plans need clinical information. The Health plans need to know that XYZ patient is in the provider’s office right now with a specific diagnosis. Today, their care team is sitting over at the Health Plan and they get notified up to10 days after-the-fact, that their patient was under care management and was in the provider’s office. If they had real-time notification of that information, they could collaborate with the provider on the treatment plan immediately and save cost. So there is a lot of cost saving by being cloud-connected and having that point-to-point connection between the provider and the health plan. Trust me, we have been trying to find this magical point-to- point connection for 15 years. And it’s a nightmare. And one of the reasons it’s a nightmare is because we have 2000 practice management systems out there and we are not going to go out and integrate all of those. So there needs to be some brokerage layer in there that enables communication that the provider is willing to consume. And, historically, providers do not want to expend a lot of money for their IT requirements.
Continue reading…
