12Dec/17

Electronic Health Records: It’s the Data. Not the App.

In seeking ways to gather and analyze – and hopefully act upon – electronic health records (EHRs), organizations are following a familiar path: They assess their needs, and then hire a vendor to support them. At this point, they’re locked into the selected vendor’s app, in terms of how they input, review and analyze data.

However, we now exist in an age in which data is delivering endless possibilities; when we pursue information discovery and seek to make good decisions from the resulting, newly acquired knowledge, we’re really only limited by our imaginations. Which is why traditional, vendor-centric approaches are no longer relevant.

In other words, it’s about the data. Not the app. Given that the EHR market is expected to grow to $33.41 billion in value by 2025, according to a forecast from Grand View Research, the stakes are too high to cling to antiquated models.

Let’s illustrate with a realistic scenario: A patient encounters blood pressure issues, even though he’s already taking medication for his condition, so a hospital doctor writes up a new prescription. Because it’s new, the doctor wants the patient to take daily blood pressure readings with an at home monitor and report back. Steady information over a stretch of time, after all, provides more value than that observed during occasional office visits.

The data isn’t difficult to collect. The patient can do it on his own, and call it into the doctor’s office. But what if the existing vendor tool doesn’t allow for the inputting of daily blood pressure readings? What if it caps this inputting to, for instance, four readings a year? In this case, both the doctor and patient are stuck with what the vendor has to offer. Sure, the doctor can work through higher-ups at the hospital to see if the vendor would upgrade the app so it’s configured for daily blood pressure readings. But the vendor may have other upgrades they need to address first, putting new requests on the back burner for months or longer.

You can apply the same sort of scenario to a patient’s weight, heart rate, blood-sugar level, cigarette/alcohol usage or any one of a number of other components which lend insights into someone’s state of health. The information is ready and available. But if the solution isn’t configured to incorporate it into a data capture/analysis program, the information will end up in limbo.

So what’s the solution?

Again, it’s about the data. Or, more precisely, thinking “data first” and then app.

Organizations should initially consider what exactly they want to capture, whether it’s blood pressure readings, cancer screenings, cholesterol checks, smoking cessation success rates, etc. Then they can figure out what kind of app will work best. Tech innovation is driving swifter and greater adoption of agile practices. IT departments are now positioned to more readily and easily develop (or pay to have developed) mini-apps to perform specialized functions – further rendering obsolete the monolithic, rigid, “our way or no way” mega-vendor tools.

All that’s required is a secured, indexable database. With this, organizations and users input whatever they wish into the database, and then build mini-apps accordingly so teams create chart visualizations, analytics tools, treatment plans, etc.

To cite another scenario, let’s say that same hospital doctor from before would like to know if her patients were picking up their prescriptions in a timely manner. Obviously, her local drug stores would have to compile and report this information to her. They could even work together to set up an alert notification system should patients fail to pick up their prescriptions within two weeks. Sounds simple, right?

Not if we’re still talking about the traditional model: The doctor might tell the vendor what she plans to do, and the vendor could respond that their product isn’t configured for data related to prescription pickups. Further complicating things, the app may need to be work with multiple reporting systems used by the various drug store companies with no way to determine if compatibility. Setting up a workable solution might take a year – or longer.

But through a modern, agile approach, the doctor simply comes up with a data collection/notification alert plan with the drug stores, has IT construct a secure, indexable database, and then design (or, again, hire someone to design) a mini-app to monitor prescription transactions, send alerts for late pickups and otherwise enable the doctor and her team to analyze various patterns within.

Or take another example: two or more unrelated entities (like a pharmacy and a diagnostics lab and a hospital) are all trying to get data into the same EHR, but if they don’t share the same EHR for the same patient (and they don’t) then they can’t do it directly.  With a standard data-based health model they could throw transactions into the same pot to be discovered by relevant applications later.

The upshot: For too many years, organizations dependent upon EHRs have resigned themselves to an “If we build it, you will come” arrangement with their vendors, i.e., the vendor builds the tool, and organizations buy in and adjust to its quirks and limitations. And being that other hands on health care priorities often take precedence, who could blame them?

But today, those same organizations can advocate for a “Let the data come first, and then we’ll build it …” strategy. By determining the intent of their discovery initiatives and data models, they necessitate COTS vendors and Open Source developers to build functionality around them. Subsequently, the market ultimately provides a better solution and HCOs end up with information that is more comprehensive, immediate, insightful and actionable – empowering them as more effective healthcare practitioners and better “custodians” of EHRs.

12Dec/17

What Healthcare Organizations Should Consider Before Migrating to the Cloud

On the surface, findings from a Healthcare Information and Management Systems Society (HIMSS) research convey a sense that healthcare organizations are universally embracing the cloud. According to the study, an estimated 84 percent currently use cloud services.

But dig a little deeper and you discover that adoption is limited, especially for critical functions related to electronic medical records (EMRs) and enterprise resource planning (ERP). Only 34 percent of healthcare organizations have migrated clinical applications and data to the cloud, and just 32 percent use the cloud for archived data and Health Information Exchange needs. In addition, less than one-quarter are turning to the cloud for back office apps and data.

In my interactions with industry executives, many say they’re testing the waters, with email, file storage and the like. Even so, they’re reluctant to wholly replace in-house datacenters with public cloud versions.  Use of EMR, ERP and analytics vendor hosting is popular, however.  But this should generally be considered as private cloud hosting in a geographically separate data center.

Yet, given the vast and often-reported benefits of the cloud – including the improvement of workflows through greater flexibility, collaboration, efficiency, rapid scalability and productivity – many of these same executives are seeing advantages in an increased presence. In determining whether the cloud is right for an organization, I stress four key considerations:

Security remains the greatest concern. Indeed, security ranked #1 among adoption barriers in the HIMSS study, as cited by 54 percent of study participants. While the sentiment is understandable, I believe the issue is somewhat overblown. Cloud vendors have more security measures in place, with more infrastructure and power. If breaches do occur, they’re usually the result of employees not adopting proper guidelines and security best practices. In my experience, following a reputable cloud vendor’s rules will keep you as or even more protected than would keeping everything on-premise.

Network reliability can be uncertain. If you use a private host for your network, you likely have strong datacenter redundancy for maximum uptime. But if you’re running your network on a public cloud, you’re entirely dependent upon the internet. If your connection to the Internet goes down, you will lose access to business-critical resources until connectivity is restored. That’s a big gamble. You could reduce risk by paying for two or three regional internet services– but this may prove too costly for some organizations. And for those in rural areas, it’s not even feasible.

Speaking of costs … If you’re planning to store massive volumes of data in the cloud, you’re looking at a hefty monthly bill – one that will typically exceed what you’d pay with an on-premise datacenter. That said, if you have a large amount of infrastructure which has to be replaced, it could make sense. You eliminate the “short-term pain” of a huge capital investment by rolling it into a monthly, operational expense. For some organizations, this approach may be more fiscally realistic.

“So what if we simply ‘dip our toes’ into the waters with a hybrid model?” This comes up in my conversations all the time. Healthcare executives want to put “safe” data assets in the public cloud, and keep more sensitive/mission-critical ones closer at hand. However, hybrid models elevate the complexities of ID management. If you extend the network over a combination of on-premise, private hosted, private cloud and/or public cloud options, you create ID management issues which could result in operations disruptions and potential employee backlash over the inability to access the data, files and apps that they need to do their jobs. HIPAA data access logging and auditing becomes a larger and more diverse challenge. Currently, there are few tools available which would help IT teams resolve these problems.  We have experience at Merlin with a very powerful tool that provides a single “pane of glass” to manage identities across all environments and many key applications regardless of where they are hosted.

As you can see, deciding whether to migrate significant IT functions to the cloud isn’t a “one size fits all” proposition. You must measure the pros and cons based upon your organization’s size, location, industry niche and other relevant factors, while also assessing the various comfort levels with any changes the cloud may bring. Finally, calculate expected ROI comparing it against the financial impact of not making the switch.

In other words, cloud migration is as much a business proposition as it is a “tech thing.” Proceed accordingly.