Ken Willett

Healthcare IT, integration, and making patient care better

Monthly Archives: March 2012

Managing A State HIE Is Going To Get Tougher

The ONC has recently published guidelines for patient security, privacy and access related to HIEs funded by the ARRA program. Given the case that sustainable funding for HIEs is already a serious issue, anything that increases HIE complexity is going to make that situation worse. The new ONC guidelines do exactly that, because they add a strong requirement for individual patient access and control to the HIE.

HIPAA already requires that patients have the ability to request EHR data from their providers, to determine who has accessed their data, and to correct any errors. The ONC guidelines now apply those same requirements to any HIE funded through the State Health Information Exchange Cooperative Agreement Program.

One of the major consequences of this rule is that the HIE will require a patient portal. Given the level of access that patients are entitled to, it’s unrealistic to expect that the state or State Designated Entity (SDE) can respond to patient access requirements any other way. Along with the portal will be a requirement for a reliable way to identify patients who are attempting to access the information in the HIE. The policy also requires that patients can designate others to access this data on their behalf.

The policy requires that individuals have meaningful choices as to whether to share their data with the HIE, and to be able to restrict access by provider. There is a strong recommendation (though not a requirement) that this control can be exercised at a finer granularity than “all or nothing”. This will place a burden on providers to either receive opt-in permission, or give the patient an opt-out opportunity, before sharing that patient’s data with the HIE. A blanket notification that data will be shared with the HIE unless the patient objects isn’t sufficient according to these guidelines.

An interesting requirement is that, in order to access data about a patient stored in the HIE, a provider must have or be in the process of establishing a treatment relationship with the patient. Presumably this is to prevent providers from using the HIE to search for new customers. But it will require very strict controls on who is allowed to access data, and leaves open the question of how the HIE would verify that a provider has a right to access the data for a particular patient.

It is important to note that these regulations only affect HIEs funded through the federal program, and specifically excludes HIEs that only support directed exchange between known parties. So one side-effect of these regulations may be to weaken state-level HIEs that “store, assemble and aggregate” data and drive providers to private HIEs, commercial clinical hubs (such as the Surescripts ePrescribing hub or the Ignis lab and radiology hub) or directed exchange networks, which aren’t governed by these policies.

What Is Cloud Computing, Anyway?

“Cloud Computing” has become a common buzz-phrase in Healthcare IT over the past few years, and as often happens with jargon like this, the definition becomes fuzzier the more people use it. This ambiguity makes it hard to really discuss the pros and cons of different remotely hosted architectures.

In common usage now, Cloud Computing or Cloud Hosting tends to mean an application is hosted remotely and accessed via an Internet connection. But the original usage of the term was much more specific: hosting of multiple instances of an application or applications on a set of servers, using Virtual Machine technology.

Prior to the Cloud explosion, remotely hosted applications generally had a set of servers for each customer. If the resource requirements for a particular customer were small, having its own servers would be very expensive. Conversely, if resource requirements grew beyond the capabilities of the current servers, an expensive hardware upgrade was required. Virtual machines allow the resources for the application to be initially limited, then smoothly increased as needs change, and a virtual machine containing the customer’s application and data can be transparently moved to new hardware.

This approach works extremely well for applications which were originally designed to support one customer. Each customer has their own dedicated computing environment in the same way as if they had their own servers: their own copy of the operating system (e.g., Windows Server), their own version of the application, and their own database. However, not all internet hosted applications operate this way. Highly scalable systems, for example Facebook and this blog site (WordPress), use a different architecture referred to as a “multi-tenant architecture”.

A multi-tenant system is designed from the ground up to support a large number of customers. There is a single instance of the application (perhaps spread across multiple servers for performance and availability) and an integrated data management system. Unlike cloud applications where a new virtual machine is created and configured for each customer, a multi-tenant system usually just requires a small amount of registration data to set up a new customer.

Multi-tenant systems minimize the per-customer maintenance work, because software updates apply to all customers immediately. Operations that cross customer boundaries, such as reporting, monitoring, and communications with other systems are simpler to implement in a multi-tenant system.

The EMR-Link lab hub system that Ignis Systems has developed is a multi-tenant system, supporting thousands of users in an integrated architecture. We believe that this is the best architecture for scalability and for data distribution from hundreds of labs and radiology services to all our providers.

So, when you look at a system that uses the term “cloud”, you may need to dig a little further to understand what that means for your particular needs, since not all applications referred to as cloud-based have the same characteristics. And a cloud solution may not be the best fit in all cases.

What We Need Is iCloud for Healthcare

The Apple iCloud system, and similar online backup systems for non-Apple systems (e.g., Carbonite and Dropbox) have added a new dimension to data backup. Yes, part of their role is to keep your data safe in case something bad happens to your computer. But they also provide a simple, intuitive way to make your data available where ever you need it. It seems that this is a capability that could be of significant use to healthcare providers with regard to their EHR data.

I’m not talking about an HIE system. HIEs attempt to address a much more complex set of problems: sharing data across organization boundaries, reconciling data about the same patient from different sources, reporting biosurveillance and immunization data to government entities, etc. What an ambulatory provider needs is much simpler: a way to get to data about his or her own patients, reliably and under a variety of circumstances.

Web-hosted EHRs can do some of this. Data is available from home or office; some of these EHRs have mobile device support; and the EHR vendor (presumably) backs up the data to insure against loss. However, the vast majority of EHR users don’t have this ability, and can only access their EHR in the office.

Healthcare practices have a range of disasters they need to protect against. Besides the usual failed hard drive, office fire or natural disaster, there is a new one: failure of an EHR vendor. There are now some 600 ATCB-certified EHRs on the market; within a few years the majority of those will no longer be in business. That means that many providers will be switching EHRs during that time, and trying to salvage their patient data to be loaded into their new EHR.

If data were stored in a cloud-based system in a neutral format, such as XML, it could readily be provided to a different EHR or to an HIE. It would also be possible to provide outcomes reporting beyond what is provided by an EHR vendor on their own internal data. Such a system would stimulate its own ecosystem of tools and applications, without requiring an EHR vendor partnership for each one.

There are risks, or course. Updates to this storage system would need to be reliable and automatic, as they are with iCloud, to assure that information was up-to-date. HIPAA requirements would need to be met to assure privacy and availability. Internet outages would still be an issue for access to this data. But overall, data availability would be much better than it is today.

Healthcare Information Exchange, From The Outside Looking In

We are now a couple of years into the ARRA-funded program to jump start HIE development at the state level. Nearly every state HIE has been defined, contracts awarded, and implementation underway. Some of the HIEs are up and running. Some of them have solid business models to fund them after the stimulus funding ends; many do not.

In parallel with this, and actually preceding it slightly, there has been an increase in the activity by health systems to set up their own HIEs. The business case for these is much more clear: the health system can tie together departments or facilities that are geographically dispersed or have different software platforms, and share data about their patients. And this HIE can be a powerful tool for connecting unaffiliated providers to their hospitals and outreach services.

In addition, smaller hospitals in certain areas have grouped together to set up cooperative HIEs. These hospitals often aren’t as much in competition as large urban medical centers are, and see value in sharing resources. They also will see some of the same patients.

All this makes sense when seen from the the hospitals’ perspective. But how does this look to a provider in the community? The provider may send patients to a variety of hospitals, and the same patient may go to more than one. Those hospitals may be members of different HIEs.

The provider may order labs from yet another hospital, or from a national reference lab that isn’t a member of the HIE. They may order diagnostic imaging studies from a commercial service provider. They may see patients from another region or even another state.

Thus, when trying to participate in this fragmented HIE world, the provider will generally have to deal with multiple HIEs. Data about a particular patient may be in several of them; and the provider may not be able to determine to which of them information about this particular visit should be sent.

The new Meaningful Use Phase 2 documents refer to a future goal of “patient-centered Health Information Exchange”. The ideal would be that a provider would have one place to go to get information about this patient; and one place to provide information about this visit. The information would follow the patient through the various organizations providing service, whether they move, change providers, or are sent to a different hospital for care.

It’s not clear that we can get to that goal on the path we are on. One model would be to roll up all the patient data into a national database. But the resistance to a national health database is very high. Another model would be a technology that allowed a patient to carry their healthcare information with them, or to select a healthcare exchange for themselves and then authorize their providers to access it. Or maybe they can store it in their smartphone and carry it with them.

iPad? iPhone? What’s the difference?

A lot is written these days about mobile device use in healthcare, but the statistics often blur the usage of tablet devices and smart phones. I think the differences are significant even though the same apps may run on both.

My wife’s mother, Maureen, got an iPad last year and she really loves it. She had never purchased a computer because the complexity was daunting. She likes the iPad because “it’s not like a computer.” But, in many ways it’s exactly like a computer.

iPad users use their devices to check email, browse the web, play games, read facebook, and watch video. Laptop users use their devices for exactly the same things. iPad users can be seen in coffee shops, on park benches, sprawled on the couch, or sitting at their desk. So can laptop users. Sure, the iPad is pretty, lightweight, has great battery life and boots up quickly. But it plugs into the same socket in your life that a laptop does.

This distinction will become more blurry with the arrival of next-generation laptops and tablets with Windows 8. Both devices will have touch screens and Metro swipe-based user interfaces. So there will be devices with keyboards that you open up, and devices without keyboards that you don’t.

The situation is very different with smart phones. People use them for email, but also a range of uses not suitable for an iPad. You can find out where you are; get buzzed when a message arrives; and, yes, make and receive phone calls. Smart phone users are seen in cars (unfortunately), walking down the street, checking messages in restaurants, and on the golf course.

The buzz around iPad use in healthcare somewhat obscured the fact that smart phone adoption has been very high in healthcare for several years. Healthcare providers don’t stop thinking about their patients just because they aren’t in the office, and important information can arrive at any time. There was a recent story (perhaps apocryphal) that a hospital provided iPads for all their doctors, who played with them for a while and then took them home to watch videos. Two recent EHR products that targeted the iPad (from GE and Epocrates) have been pulled from the market, so the novelty may be wearing off. But the smart phone? It’s here to stay.