Setting Your Data Free

By the UI Guy

As its nomination for “Most Overrated Technology” at HIStalk’s 2010 HISsie Awards demonstrates, Service Oriented Architecture (SOA) is a term too often bandied about by healthcare IT vendors. It’s not the nomenclature itself that’s the problem, but rather its misuse and the unwillingness of many of these vendors to do anything more than pay it lip service.

This shortsighted approach is reflected in products that require too much local functionality, time-consuming client-side data management and restrictive allegiances to pre-defined operating systems and form factors. The latter limits the advance of healthcare mobility, as the form factor of choice remains desktop applications that tie clinicians down. When companies do create mobile apps, users often face similar limitations – they’re only for one device – such as the iPhone – and rely on functionality that does not make the best use of the device’s attributes.

Another challenge is that the data collected by many applications is housed in silos – it’s unusable across the 30, 40, 50 or more disparate systems that hospitals typically have. It seems like many vendors are developing in a vacuum and then slapping an SOA badge of honor on their technology, without meeting the key criteria of true SOA – collecting data from numerous device types, via any operating system and platform and making this data usable by other systems.

Developing high-impact products involves a commitment to SOA at the conceptual level. Part of this is versioning HIT applications to take advantage of certain form factors, rather than trying to cram features into the device, come what may. For example, a product versioned for the iPad would make the most of of the large screen, light bodyweight and long battery life, and also multi-touch. If a vendor can’t apply its products across multiple device types, getting the most from the merits of each, this should be a red flag that the product is not really embracing SOA.

The next step to developing SOA-focused software is to create a simple and intuitive UI that makes it easy to capture data. By embracing industry standard web services methodologies and universal exchange approaches like XML and HL7, this data can be made usable across multiple systems and databases.

Patient information should be accessible from mobile devices, so that it has maximum impact on clinical floors. This in turn extends data retrieval and management capabilities to a wide user group. For example, if patient data is captured at the point of admission by an enterprise forms management system, the application should be able to pre-populate clinical forms with this information on a tablet carried by a nurse. Such synchronization eliminates delays and redundant effort.

If captured data is stored or managed at a server level – rather than locally as is the problem with a lot of SOA impostors – users will have a more focused interaction experience and will be freed from unnecessarily top-heavy interfaces. By separating data from the UI once it has been captured, developers can free clinicians to perform tasks quickly and get back to focusing on what really counts – delivering timely and informed patient care. Without such a switch in design philosophy, SOA is just another ingredient in the revolting acronym soup that HIT vendors have been serving to hospitals in recent years.

Peter Hudson, MD is Co-Founder and CEO of Healthagen

When did you decide that you wanted to start this company? Can you just walk us a little bit through what’s happened over the last couple of years from inception to where you are today?

Wayne Guerra and I are both ER docs, so we’ve seen 50,000 patients around the point-of-care. Over the last three or four years we just realized that patients weren’t sure where they should go. They often ask us questions: “Is this the right place? What should I be worrying about? Was this the best place for me to come for the condition that I have?”

The genesis was a Saturday morning, trying to get the kids off to soccer and I got three calls from different neighbors who not only weren’t sure what they had – they had a symptom, or their kid had a symptom or had an accident – and they weren’t sure what to worry about, and how to think about it.

Then, when they sort of settled on what they were most worried about, where should they go? What kind of facility, and then where. Exactly where – the latitude and longitude, address, and phone number. I was really surprised by that because these people had lived in our community for years and they’d probably driven near hospitals and urgent cares and things like that and they just weren’t aware of it.

We realized that there’s a real need for answering those two simple questions [what could be wrong, and where should I go], which aren’t really that simple when you realize how much content is required for the first one – which is kind of a clinical question; and how much data and location specific data is required for the second one. As mobile technology became available and the landscape for distributing software became more open, we felt that was a perfect opportunity.

At what point did your vision of an opportunity to create this valuable tool go from ‘let’s build an iPhone app’ to ‘let’s build a company that we can build a platform for providing consumer-based health information’?

We’ve been thinking about this for awhile because there’s just so little that’s known about the details of healthcare – how much does this cost; what’s the best treatment for this; who’s the specialist to take care of this condition? We felt like there was this huge information gap and inefficiency. We started thinking about that even before we realized that this product could be a good entry point for some of that.

But as we thought about our initial product, it was never about just being an iPhone app; it was about being a decision platform for people. We modeled this entire thing out with a comprehensive flow chart from start to all sorts of different finish points with every data set that we needed completed. Our product does what we modeled. I guess having provided medical care, having been patients, and having talked to so many patients, we just had a really clear view of what we saw to be some of the problems. Natural places where different data sets could really provide information to patients within a context of the decision they needed to make.

See, from my perspective, the application is a very nice application. It looks like you guys have done a great job, but there’s a lot more here than I think most people would expect. I say that because for one, the founders are a couple of long-practicing physicians. It’s not like you just started residency and then decided to start a software development business. But then, you start to uncover a little bit more, and it’s quite impressive that you guys have a fairly serious group of people behind your company and you look pretty serious about it.

We’re extremely serious about it. We think that patients deserve, really, a very robust, very connected resource at their side and it’s possible, so why not have it? We went out to a lot of the largest companies that could help us for the data needs and we shared our vision, and they partnered with us. We went to large health systems and we talked about what we were doing and they became our clients.

We rolled our software out and then asked people for stories about how they used it, and they used it in every way we designed it for and got benefit from it. In fact, we’ve had very few comments saying anything other than ‘can you add this disease or that one because I didn’t see it on there?’ Most of it has been ‘I had a problem. I now have a way to think through it because I want to be empowered. I want the information when I need it and I made a decision. I was really happy with my decision.’

It’s been extremely rewarding. As much as taking care of patients one-on-one in the hospital; now we can take care of and help people in a sort of one-to-many, or a much larger focus.

When did you first launch the first version of your application?

March 10^th of last year – about a year ago.

I’m very impressed because you guys are covering a lot of ground very quickly. Where do you see yourselves, as a company, in a year?

I think we’ve tackled one of the harder parts of a consumer-facing technology for healthcare, and that’s real-time decision support with real-time access to over a million data points around the country. We will be expanding into helping people manage their health; helping people learn more about their health, and promoting different capabilities of improving their lives. You know, getting healthier.

With the knowledge that they have the value-add of thinking through an acute problem. It’s always there. Thinking through how to access the system is always there. I think that’s more of our vision of where we’ll be in a year.

Our current technology, which we call symptom-to-provider technology, we see it as a flow chart or a flow of information that goes down many different pathways, but the same kinds of pathways, the same categories of pathways. We envision it becoming more engaging on the front-end with more specificity for the patient, and better connections to our clients on the back end. So, as you access the system, we’ll become more and more integrated and valuable to both the hospital and the patient in facilitating their entry point to the healthcare system.

When it comes to building consumer-oriented solutions, like PHRs, the prevailing attitude seems to be ‘let’s build it and they will come.’ I think that’s far from true. Your application is one of the first that I’ve seen that, as a patient, as a potential consumer of this application, you’ve actually given me a compelling reason to use it. I think that’s extraordinarily unique.

The challenge is then, how do you make people like me aware that you guys exist?

That’s why we have partners. That’s why, in every market, we have clients and they promote us, but you’re absolutely right. As to the first part of your question, I think there’s something that other vendors in the chronic disease space and the personal health records space should think about:

When and how do you engage somebody? People say that if you have this cool graphing technology for your glucose on your phone, that it’s engaging. That if your glucometer connects to the rest of the world and shares your data with your doctors and they can give you feedback, it’s engaging. I think those are connecting and those are efficient. Those are good ways to collect data and connect with data, but they’re not engaging.

I think that the moment of engagement comes when somebody has something wrong. I know this personally because people come into the ER with all sorts of chronic problems, for example, perhaps they’re an alcoholic and are drinking themselves to death. Every now and then if I’m around on a shift when they sober up I’ll say, “Listen, you’ve got to stop drinking. You’re going to kill yourself.” I’m never afraid to tell people exactly what I believe to be the truth – if you keep drinking you’re going to be dead. Every now and then somebody comes back and says, “You know what? I stopped drinking, Doc, cause you told me that I needed to stop drinking; that I was going to die.” Information combined with an event that helps someone take notice. That’s engagement.

Ultimately, if you have a technology that will help people track their weight or what they eat, or their nutrition, or what their glucose is – all that is great if they want to do it, but I think they probably need some event to promote their interest in doing it and what a better chance to engage somebody than to help connect them right at the point-of-care, right at the point of need, with the right solution.

Then guess what? Some of our partners are pretty interested in the fact that we have real-time surveillance of where people are going. And, can they engage with people and help them because they see that ER visit, or they see the urgent care visit or their interest in certain conditions being a sign of worsening or a sign of exacerbation of their condition.

I guess it’s something you’re probably used to dealing with, really. But to me, the frustrating part would be that how many people will go through a crisis and not really know how to respond, or don’t adequately respond because they don’t have the tool available. It won’t be until after the fact, and maybe never, for them to know that there is such a tool available and at their disposal.

You’re right, it becomes compelling and it becomes engaging when you need it. I suspect that’s the challenge for you guys is to get out there and get people’s attention before they need it, so when the need does arise, that you’re at hand.

I think that’s one of the reasons why we love talking to you and other people who have an audience. There’s huge businesses built on moving the needle for a population one-percent. It doesn’t take a huge amount of engagement to actually make a big difference, and then it becomes something that continues to snowball when people hear about it.

What is your exit strategy? You’re an entrepreneur, you’ve built a business. You guys are tracking nicely. What’s the end game?

Our exit strategy is really to keep our head down and to continue to add more and more data, add more and more hospitals, and provide some benefit to some populations that we’re talking with. Cost and quality information, personal health record access, etc. To some degree, it could look like we’re trying to do a lot of different things, but in my mind it’s so connected and so structured that it all fits together. I think we just want to keep building the best solution and see what happens.

Ultimately, somebody will realize that 130-million patients a year go to the ER; another 60-million go to urgent cares, and something like 800-million see the doctor. In all these decisions there is inefficiency and waste, in the hundreds of billions of dollars. If all of a sudden there’s a mobile solution that really facilitates that access and helps people think about it in the right way, it’s going to be compelling for somebody. We’re quietly building it.

Is there anything that I haven’t asked, or anything specific that you would like people to know either about the application or about your company that you feel we didn’t cover?

From a CIO’s perspective, or somebody in information technology, we offer a platform to communicate certain really key hospital system variables to patients in a very simple format, and offer many pathways to further enhance the patient experience through integration. Initially, this can even be marketing data, but the other integration opportunities are very defined, simple to execute on, and can provide meaningful revenue opportunities for your organization. I think that, especially with your audience, is a key message to get across.

Thanks, David, for taking the time to talk with me.

Scott Storrer is President and CEO of MEDecision

Thank you for joining us today. To get things started, can you tell me a little bit about MEDecision’s history and the evolution of the company?

The company was started in 1988. I’d say, for the first 10 years our primary focus was to sell case management, utilization management, and disease management systems to health payers: many of the Blue Cross/Blue Shield organizations, along with other non-Blues. So for the first 10 years MEDecision really dominated in the payer market.

What we realized about halfway through year 10, was that we had kind of mastered the integration within the four walls of the payer. We really saw the power to begin to make that degree of integration external – i.e. to connect the case manager directly to the physician.

About 8 to 10 years ago we launched a product called iEXCHANGE, which essentially allowed physicians to do online real-time authorizations and referrals, and also to share what I would say, were low degrees of content between the physician and the case manager.

Then, about four years ago we began broadening the iEXCHANGE product and transforming it into a product which we now call Nexalign. It allows us to take payer-based data, and also case management notes, and put it into Nexalign. Within Nexalign, that data essentially bangs up against our proprietary clinical analytics and it identifies gaps in care in a patient’s treatment. Then, depending on those gaps, it puts forth a proactive treatment plan that both the case manager, and also the physician, can follow with a patient.

So if you think about it, our core has been around the payer market. Eight to ten years ago we saw the value of connecting the provider to the case manager. Then, most recently in the last four years, say, really has been the development effort around a product capability called Nexalign. Again, what that does now is it allows us to develop these clinical summaries which we can share back, on a real-time basis, to the case manager in the payer world, and also directly out to the provider.

Last year we acquired a company called Hx Technologies. HxTI was a company that was about 9-years-old that had with it several legacy HIE customers. We acquired the company because we saw the strategic opportunity to begin, on a regional basis, to enter into the HIE space with the ability to stitch together the disparate providers of EMR systems, and also other sources of ancillary data. So it gave us the ability to start bringing real-time clinical information into the Nexalign product and to marry the payer-based data that we have with real-time provider-based data and develop the most meaningful clinical summaries in the marketplace.

So again, we acquired HxTI last year and had fully integrated the company by year end. Then, just before HIMSS in March we launched the new HIE product called InFrame.

What also is important to know about us, when you think of us, we do dominate the payer space today. I’d say one-in-six insured Americans is managed on our platforms. That gives us access, in collaboration with our payer customers, to somewhere in the range of about 45-50 million individuals – medical history and case management notes.

Again, from a data perspective, this is a company that, in collaboration with its customers, is rich in data.

Is it true that most of the information that you have from the payer side, that’s within the context of case management and disease management?

Yeah, it would be that and, essentially, it’s the core claims data, lab, some degree of pharmacy, and then the payer-based case management. So if there’s something unique in a disease management program and a case management program, or unique within the notes for utilization management, we’re also able to bring that into the Nexalign analytical tool.

For years, the best data that’s been out in the market really has been the payer-based data. Where we had a leg-up for years is we actually were able to augment that with the case management notes, broadly. But we got to the point where products, with the power of analytics, can augment that data set with the real-time data that’s coming right from the provider at the point-of-care, so there’s quite a bit of power that brings to treating individuals and creating alerts. If you think about it, a lot of the payer-based data that’s being analyzed out there, generally, is about a month old.

Or, in some situations, we’re working with customers to get a cycle time down to two weeks. If you get to a world where you have payer-based data at about a two week level, and at the same time you have the ability to bring in real-time clinician data and run the rules set against that and create these treatment plans, it’s just that much more actionable.

With InFrame, we have several pure HIE customers. In Philadelphia, Fox Chase Cancer Center has developed the Fox Chase Health Information Exchange which digitally connects the center to its extensive network of partner hospitals and affiliates across the mid-Atlantic region. This allows them to remotely interpret advanced oncology imaging, such as PET/CT, so that patients do not have to leave their communities to receive world class care. It also means that partners can move more quickly to market with the latest diagnostic services, leveraging Fox Chase staff and expertise. That’s an example where InFrame’s standalone. Nexalign also can be sold standalone.

Then, Alineo, as you know, that is our core case management suite of products. Or, I should say the Alineo is the new capability of our legacy product, which was launched two years ago. We’re actually in the process of migrating our customer base over to the new Alineo product, but when you bring them all together is when it’s really powerful.

Now obviously, you guys have some great applications and functionality imbedded into your HIE solution. Are you interested, are you actively looking at initiating the conversation with a region to be a pure middleware provider?

You mean, as far as responding to more of the state HIE bids?

Yes. I mean, are you looking at going after some of the business where you’re not looking at deploying a high degree of functionality on the front-end, but you’re really interested in potentially getting in and being a participant, and sort of connecting the dots.

Oh, absolutely. Again, just a quick commercial on InFrame – InFrame was based on Hx Technology’s legacy product. As we integrated it last year, we made a number of meaningful modifications to the product and then launched it this year as InFrame. There are several market leading aspects to it, which really do create differentiation.

First off, and this is credit to Hx Technologies, but essentially, its founder, Dr. Elliot Menschik, has been very active with all the HIE Connectathons and those types of initiatives for a number of years. He’s been at the Interoperability Showcase at HIMSS. He’s been a key-note speaker on the topic of health information exchange for a long time.

The key there that I want to make with InFrame is today, that product can truly plug and play with anywhere between 80 and 90 of the major vendors that are out there; whether they’re EMR systems for other provider-based systems – Google’s applications, Microsoft, you name it. From an interoperability standpoint, there’s a tremendous amount of flexibility.

The other piece of it is HxTI really cut its teeth on distribution of scans and images, so it kind of grew up as a radiology exchange. To the best of our knowledge, it’s the only HIE infrastructure that is out there today that can transmit a diagnostic-quality image. What’s interesting here is from a state bid perspective, InFrame differentiates again because of its ability to connect. We’re finding the radiology component tremendously meaningful as we’re working through these opportunities. But I would also say that what is of interest to a state is the fact that MEDecision – 4 out of 10 times – has the payer as a customer in that state also; the two kind of go hand-in-hand when it comes to differentiation.

I like the story of HIE vendors who are just very clear about building an open platform. They may offer their own high-value applications to use that information, but they’re also very committed to supporting an open platform and welcoming third-party solutions. Obviously, historically, that’s been a huge limitation.

I tend to think that regardless of what vendors say anyway, if you want to be in this space, I can’t imagine a region investing in HIE and not having it be an open platform.

We’re right with you. It absolutely has to be open. If you think about another way that we differentiate from the other vendors – its support and mobility. One: we differentiate with InFrame because not only can we aggregate the data – go out, hunt it down, bring it in – but again, with the Nexalign product we have the ability to analyze that data. Some EMR companies would say within their four walls they can aggregate the data. They say they have analytics, but I think you know truly, they do not.

So again, what’s great about this is with InFrame, not only can we go into a state situation, but also we’re finding B2B opportunities. You know, Exeter hospital in New Hampshire is a current client of ours and we’re working with their outpatient facilities which run on…one’s on NextGen, one’s on Centricity. I don’t know the third player. I think it’s Epic or Allscripts. Essentially, what we’re doing is we’re stitching all of those systems together for the Exeter hospital system. But really what’s of value for Exeter is not only can we stitch together, but when we bring it together we have the ability to apply clinical analytics to that data; which again, none of those disparate EMR systems really have, to create meaning for the physician use. That’s a pretty important point of differentiation for us.

On mobility, we do agree with your definition of mobility. It’s really, how do you begin to move the data around? One of the things that we are talking with several of the large EMR companies with – now again, we do this with permission from our payer-based customers – but we are actually beginning to pilot pre-populating EMR systems with the payer-based data. Again, if you think about it, if you’re going live on GE’s Centricity system, it takes the doctor a year to maybe two years to get really, any meaningful data into that box, so to say, to create value at a patient interface.

What we can do is we can go back for up to five years and essentially, pre-populate five years of payer-based data into that EMR. Then, at the same time, create a clinical summary. Now again, that’s mobility in a broad definition using the Alineo data that we get from our payer-based customers, running it through Nexalign, and then pushing it into the EMR system. At the same time, once it’s in that one EMR system – as an example, if our HIE solution is deployed within that hospital group – again, once it’s in that one EMR system it can be shared amongst any other system that we’ll connect with. Or, any other HIE that connects into that system.

How usable is the payer-based data? When I say usable, I mean how accessible is it in terms of, are the payers willing to let you push that information in a broader HIE platform? Or, is it only to be used in very specific and strict use cases?

About 50 percent of our customer base tends to be more progressive on the payer side. These customers are the ones that, to be honest, when we go out to market our core care management systems, they now want to hear how we can help them with HIE. So how can we help them? I don’t know how familiar you are with Patient-Centered Medical Home models, but we can help on fronts or situations where the state governments are beginning to force them to interface with state-mandated HIEs.

So the more progressive, kind of forward looking payers are finally saying, “Listen, the dividing wall between payer-based data and provider-based data really has to come down.” That war is over. We’ve got to stop saying one data set is richer than the other, because the reality is neither one is 100% complete. But when you can bring those two together and analyze them at the same time; that is when both of the parties – the providers, and also the payers – are sitting back and saying, “Wow, this is truly impactful.”

There are some instances where plans have been slow to adopt some of our capabilities. I would say the intermediaries are really the pipes here. You’ve got companies like Availity; I’d say Emdeon, RealMed, NaviNet – these are really the claims clearing houses for providers.

Essentially, they’re taking the claim and pushing it through their exchanges back to the payers. We have partnered successfully with Availity, and we’re beginning to talk seriously with one other to have the rights to distribute patient clinical summaries, which Nexalign creates. Even though the summary data won’t be housed in an EMR, as an example, it will go from the Alineo into Nexalign. It then will travel through the Availity pipe to the provider portal within a provider’s office.

So we’re starting to see movement on that end, but actually getting to the end destination with data where it’s stored in an EMR – I know I’m repeating myself – but generally, we only have, right now, acceptance from about 50 percent of our customer base.

Are you looking to do anything in the way of more traditional mobile solutions?

Yes, in our development roadmap we will be resourcing the latter half of this year, and also all through 2011, on how do we begin to plug and play with a lot of the mobile apps that are out there to share this data; whether it’s the clinical summaries all the way through to case management notes, you name it.

The other area that we’re looking big at right now is the whole area of telehealth and telemedicine. From a device perspective – even though these aren’t what you’d traditionally think of a PDA or a cell phone – there are several companies out there now that have whole monitoring devices that are all Bluetooth enabled; which we have interest in because, again, this would give us much greater access to real critical pieces of real-time data that we need to make our clinical summaries that much more powerful.

To be able to pick up a diabetes monitor, in real-time, when somebody’s monitoring themselves in the bathroom after lunch and, in real-time, bring that information via Bluetooth technology into our environment, into our analytics and clinical summaries. And to send alerts out to that person’s family member – whether it’s a child that’s having an issue with glucose levels, for example, which we could share that via a mobile device. Or, it could send an alert right to the primary care physician, which then sends an alert back to the patient’s case manager.

That whole area is really where we’re looking hard right now to go; either on acquisition, or partnership with a device manufacturer and distributor.

Is there anything else that you would like to add? Any final thoughts?

At MEDecision, we’ve been in data sharing now, really, for the past 22 years. But the clinical summaries, which all of our customers’ case managers operate off of, that’s a core competency for us. That’s what we’ve been doing, and that’s really what this company’s been built on – is how do you take that claims-based data and that case management data and, using the analytics, how do you really bring meaningful use to the case manager’s desk?

Really, what we’ve begun to do; and we started four years ago with it, so it’s not like we’re just doing this overnight – is how do you take those same concepts down to the provider world and create that same meaning for them through the use of data? But what’s great about it is we’ve got the tool kit now to not only capture the provider-based data to bring it together, but at the same time, we bring along with that the potential of data on 50-million Americans – depending on customer appetite — to allow us to share that data.

I guess that’s just kind of a re-cap of everything we talked about, but it really is a shift out there right now. I think HIE is what’s going to enable that shift.

Microsoft Throws Interesting Win 7 Mobile Ingredients into the MIX

By The UI Guy

When Steve Ballmer failed to unveil the Courier tablet at CES 2010, the blogosphere went back to ignoring Microsoft (who we’ll call MSFT for fun) as everyone from techies to cable news presenters – who wouldn’t know a mobile app from a hole in the ground – switched their child-like attention spans to the Apple hypefest.

While all eyes were on Steve Jobs and co., MSFT debuted the Windows Phone 7 Series in Barcelona at Mobile World Congress 2010. This announcement garnered some media attention, but it was a mere sideshow during the iPad circus. Undaunted, Microsoft continued to work on practical tools for the 7 series – including those that could have more impact on the healthcare mobility space than anything with an “i” prefix.

Last week MSFT delighted its developer and designer base, which far exceeds Apple’s in depth, breadth and business focus, with the release of a new toolkit for the Windows 7 phone at the Mix10 show. Not too many surprises, as we knew that most likely the new mobile OS would be a flavor of Silverlight. However with the launch of Silverlight 4 Beta, MSFT has opened up a dedicated suite that was built from the ground up to support the new Windows Mobile 7 OS.

This is a strong strategic move for Ballmer, Gates et al. With the SDK being primarily a flavor of Silverlight software, vendors and app developers that focus on the .net framework will be able to re-purpose their work for the Win Mo 7 platform with ease.

In contrast to Apple, which let its developer base figure out its SDKs for themselves, Microsoft has essentially created a plug and play kit with transparent and usable features. With Blend 4, a user simply opens the program, and selects “Open a new template for Windows Mobile.” It’s then just a matter of porting over previous work. Anyone that’s a MSFT developer is now a WinMo developer. There is no learning curve, and traditional Windows apps can become fully functional on WinMo 7 devices within weeks. Yes, you read that right. Think of the possibilities.

Too often we distill the viability of a platform to the number of its available apps. If you believed the mainstream press, you’d think that Apple is in an unassailable position because of the sheer quantity of offerings in its App Store. But when it comes to impacting business, including healthcare, volume counts for nothing. Healthcare providers need focused applications that solve real-world problems. MSFT is making it easier for developers to create these by taking the hassle out of SDK use.

There could be some very interesting things done with some of the preliminary components of the tool kit including:

• Hardware acceleration for video and graphics
• Accelerometer for motion sensing
• Multi-touch
• Camera and microphone
• Location awareness
• Push notifications
• Native phone functionality

Two of these – the accelerometer and multi-touch capability may not overcome objections from Applephiles, but they do at least put MSFT on a level footing in two areas dominated until now by Apple.

Yet, arguably the most important to note is the native push notifications. Whether you use Gmail, Outlook or any other e-mail system, you likely get e-mail notification bubbles in the bottom right corner of your screen when new messages arrive. The new Microsoft platform will enable software developers to create similar real-time notifications, but via the OS instead of a browser.

For a hospital using enterprise forms management, relevant users, such as nurses, could be notified on their WinMo devices when a newly admitted patient’s forms are incorporated into the EHR, prompting them to prepare for that patient’s arrival on the clinical floor. There are dozens of other possible use cases across the facility for those staff that need up to date access to information outside of a browser environment.

Location awareness could also be significant, as healthcare software could present information only relevant to where a care provider is. For example, a physician who is registered at several hospitals would be presented with a targeted set of patient data depending on which location he or she was at. This would enable clinicians to be more focused, by eliminating redundant information.

The second interesting release last week was the debut of Internet Explorer 9. What I found most interesting is the support for HTML 5, and more importantly SVG (Scalable Vector Graphics). It’s great to see MSFT heading into this space sooner than later, indicating that they will be at the forefront of providing UI development and design tools for this powerful new iteration of HTML.

Much of the concern within the design space is that there has not been any real design software released specifically for HTML 5. Microsoft’s splash in HTML will likely spur Adobe to make further enhancements to Flash, leading to competition-fueled innovation that has been previously lacking. As with the WinMo 7 SDK toolkit, developers are salivating over the prospect of intuitive, usable development tools that will enable them to bring high-impact healthcare technology to mobile users. It promises to be an interesting few months for Windows watchers. MSFT may not have the pizzaz of its fruitily-named competitor, but when it comes to moving healthcare IT mobility forward, the Seattle-based powerhouse is proving it cannot be ignored.

Paul Brient is President and CEO of PatientKeeper

How does PatientKeeper help organizations achieve meaningful use?

The evolution of PatientKeeper has been very much about automating a day in the life of a physician. We got started much like MercuryMD did, although we started on the charge capture side, which is a small piece of what physicians do. Over the last 10 years we have built applications that support just about everything that a physician does.

Before the ARRA was passed and meaningful use was defined, the one product area we had not taken on was physician order entry. Now, with the definition of meaningful use and the acceleration of that market – or at least the proposed acceleration of that market – we have gone full force into building a CPOE solution which we actually had already designed and had “in our back pocket”. We raised a bunch of money and are going forward with building it. We signed our first customer and hopefully we will sign several more before HIMSS. We will be deploying it in the October-November time-frame.

So, the short answer is about 80 percent of the meaningful use measures are physician-facing; that is they require the physicians to do something; to use it. We will supply our clients with the ability to meet all of those physician-facing requirements of meaningful use.

I know that if you were to go in and run reports showing the frequency of direct physician interaction with legacy systems in the HIS environment, a lot of vendors – not to mention hospital CIOs – would be very embarrassed.

Yes they would. We have run those in fact. It’s a small number.

Clearly, the meaningful use criteria require direct clinician interaction, and ultimately adoption of the technology. If you told me that your adoption rates were 3 or 4 times greater than those legacy systems, I would think you were being extremely conservative. Having said that, how do you build a business model around being the "adoption layer" of technology?

Well, we’re more than the adoption layer. We now have 12 different applications. With CPOE we’ll have 13. We are fundamentally all about technology that supports physician workflow.

It isn’t just about looking at results, or just about trying to expose legacy systems in clever ways. We have a full stack of applications that do all of the functions that meaningful use requires. Now, CPOE is obviously about physicians putting in orders. We push those back to a back-end system, but the full order workflow for physicians and their supporting staff like nurses and ward clerks is all in the PatientKeeper system.

This is quite similar to our sign-out product, which is a little more straightforward. That’s an application that mostly stays in PatientKeeper to keep it distinct from the legal medical record. Sign-out is a proper application with business logic, and all that good stuff, that automates the sign-out process between physicians.

So, our business model is very much around selling applications to hospitals and enabling them to meet meaningful use criteria.

You know, you first have to get physician adoption, and most hospitals are still struggling to get doctors to use any technology. We’ve been very successful at getting adoption rates into the 70-80-90 percent rate, which is well more than double what the current HIS system has. Then, we also add to that functionality; for example, active problem list management. We have a problem list application which many organizations don’t have. Forget about the fact that the physicians wouldn’t use it if it were part of the core system – because they’re not using the core system – it’s not even available.

We add net application functionality. We look very much like – I won’t say a traditional application vendor because our technology approach and the fact that we’re a layer on “top of” is a little unique – but we sell software and create a tremendous amount of value for our clients. If you think of being able to meet meaningful use requirements without ripping and replacing your existing systems, to do so for a fraction of the cost of going out and buying a new system- in a half or a third of the time – then that’s a lot of value creation. So, we’re pretty excited about that.

Is it typically assumed by a hospital that their CPOE system is going to be provided by their core system, or are they attuned to the fact that no, they’re not going to get it from Cerner, or McKesson, or whoever it might be and that they need to talk to PatientKeeper?

Well, traditionally there really was only one choice. You had to buy a core system in order to get CPOE, and you got it from the core vendor. Obviously, given the adoption rates of core systems – and even worse, the adoption rates of CPOE, especially in the community setting, which are very low, single digits – that hasn’t been a very successful strategy.

I think we are one of the only… I’m sure HIMSS will tell us whether there are others that are approaching it this way. There aren’t any other systems that I know of that allow you to buy CPOE as an application to run on top of your current core system.

We think it is very important to decouple those two because you’re talking about automating physicians and not automating hospitals. So, let’s automate the physician. Obviously we have to send that data to the hospital system so they can fill the orders and do all that workflow, but that’s a well established workflow and if you try to just expose that to the doctors, it doesn’t work for the doctors. The doctors don’t use it. It’s really not going to help you on the meaningful use criteria since they were clever enough to say that meaningful use means people really use it, and not that you just have it.

It is not something that if you call up 100 CIOs, they’re going to go: “Oh, yeah, we have these two options. We can buy an add-on physician workflow, CPOE system or we can go to our core vendor.” Part of our big push at HIMSS is very much to let people know that we’re an option.

Maybe we’re not the right option for everybody, but we’re certainly at least worth thinking through as an option to, you know: “I’m a Meditech shop. I can either try to deploy Meditech Magic POM – which we know doesn’t work. I can try to upgrade to Meditech 6.0 – which might work. Or, I can rip it out and put in a Cerner or a McKesson – which several of those systems haven’t worked terribly well either.”

We’re all about an alternative. Here’s a different approach. Our CPOE product is not just a “me-too” product. It was designed for community physicians and based on a whole bunch of design principles that in some ways fly in the face of what a lot of traditional, more academic medical center- based CPOE systems do.

Do you have confidence that when the dust settles, meaningful use will be based on actual clinical adoption and not simply whether an organization purchased the prescribed laundry list of certified systems?

Certainly they’re going about it in the right way. The stage one criteria for CPOE is very much around 10 percent of the orders have to be put in directly by doctors. The government originally thought phase two would be a hundred percent, but they’ve signaled that they are backing off of that.

Let’s say its 50 or 60 percent. You and I both know that around the country in community settings, well less than 50 percent of physicians ever sign in to the core HIS system. Well less… like 10 percent. You look at the 10 percent hurdle and you go, I can probably somehow get there. That’s not a very big hurdle.

But, if it get’s anywhere north of that these systems aren’t going to support it unless they do something radical with their doctors, which in a community setting, you don’t have a lot of levers to pull. Doctors aren’t getting paid to do it. They’re voluntary physicians. In the academic world, or if you’ve employed all of your doctors, you can have a different argument. In the community world, it’s a non-starter.

We’ve got a lot of clients that have tried CPOE and have failed miserably. Just doing it again, now because the government said so, isn’t really going to produce a different result, right? We are very confident, first off that our CPOE will save doctors time, so they’ll want to use it. At the end of the day, if you’re going to give me some technology and it doesn’t save me any time, and doesn’t benefit me, why would I use it? And, that’s kind of what the old CPOE strategy is – well, it’s maybe time-neutral, at best, and it really isn’t.

What if I gave you a CPOE product that cut your rounding time in half? Now would you use it? So far the answer from the doctors that we’ve engaged in with our product is “Absolutely, thank God.”  What we are doing is a big change. It’s a significant departure from the approaches in the past. We’re all about that non-employed physician in the community that maybe goes to a couple of hospitals, who’s trying to make a living in an increasingly difficult-world. Slowing them down is just a non-starter.

I understand that you have been fairly involved with HIE through the PatientKeeper Community Connector solution that you offer. How important is HIE to PatientKeeper’s overall strategy?

Our approach to HIE, in some ways, is philosophically similar to the approach of the rest of our applications, which is “let’s make sure that we solve a problem with HIE that helps the physician”. So many HIE efforts have failed, just look at what happened in California and many other parts of the country.  Even where people have been successful with building an HIE or RHIO or a CHIN, or whatever you want to call it, physicians don’t really use it because it is separate from their core workflow. 

Our approach to HIE certainly involves exchanging clinical data –we do that all the time, so that’s not a big technological challenge for us. The real question is how do you do that in a way that is meaningful to the doctors and doesn’t slow them down and works in the context of their workflow.   Consequently, we prefer to work on HIE projects that are at the community level, where you have a couple of hospitals and the physicians in the community and start moving data there. Since most of the care that people receive is in their community this has most relevance and the most impact.

To the extent that people want to build HIEs that connect the country and allow me to go to Colorado and break my leg and get my medical records – that’s great. That’s useful to the patient, and will be useful to whatever doctor saw me down there, too. We, PatientKeeper, don’t necessarily want to play in that world, per se.

At PatientKeeper we are much more about connecting communities. We’re doing that in most of the places where we have clients. So, it really depends on how you define HIE. On almost every deployment that we do, we’re connecting something to something, and increasingly we’re focused on connecting EMRs as more and more physicians get EMRs.  One of the unexpected challenges we encountered is that we are finding that a lot of the EMR systems that are in production can’t connect. Physicians have to upgrade to the latest version or a version that’s coming out in 3 or 4 months before they can really plug-in nicely into the HIE world.

What is your view of a sustainable HIE? What is a business model that will work?

One of the things I like to remind our company is the simple fact that if our customers have no business model, we have no business model. So with much of the HIE activity (and the CHIN and RHIOs before them), one has to ask what problem are you solving? And it’s really expensive to solve the problem of – I go to Colorado skiing and break my leg and a physician can get my medical records. Is it really that useful? The doctor still has to take an H&P. It’s hard to really get excited about that as a way to spend billions of dollars, and operate a big enterprise.

Our company’s stance is – and I feel this same way personally – that we’re reasonably skeptical of what we call “standalone” HIEs. You know, go build an organization, go try to put all of this data in one place, and then ask people to go look at it – because I don’t think that solves enough of a problem to create any economic value for anyone to pay for it. Almost all of them have been funded through grants, which are one time grants. The grant runs out, and now you go out of business.

We’re more excited, though… at the local level, there really is value. That’s where most of the patients are – obviously if you’re in a community – and where most of the healthcare is delivered. There’s a lot of need for moving data around and understanding what medications people have, and just the simple thing of, if I do a referral to somebody, it’d be nice to do it electronically. So, there is some real value that is created locally.

The problem still remains – who pays for it? Where we’re seeing some good traction and some sustainability is where someone’s deployed our technology – and once you deploy either our Web product or our portal, or our handheld products, or both –they’ve solved all of these integration challenges that are in many ways the same integration challenges that you would solve in an HIE. A lot of our customers are saying, “Didn’t we already do this? And, if we just agree to work with the hospital across town, or with these 5 large practices and have them just link in, and do the integration just one more time for small dollars, don’t we have an HIE?”

And the answer is – Yes. I don’t know what the definitions out there are, officially. Someone out there might say, “No, it doesn’t count.” But it solves a lot of problems, and it doesn’t really cost anything more. You put it on the same servers, and it’s some incremental services work to do the integrations, which in some ways, in the outpatient world are significantly easier than in the inpatient world. It’s not even a particularly challenging problem technologically. It’s more operationally and politically getting everyone to agree. Once you get everyone to agree to do it, it’s pretty straight forward. Then, you do it in the context of something that’s already there. The incremental cost is low and the value is high. You know, it’s not going to change the world – but it’s kind of nice if I’m a doctor and I’m using a PatientKeeper system and I can whip out my iPhone when I get a new patient and I can see their meds and allergies from the other doctors in the community.

You know, that’s actually useful. Still have to take an H&P, so I don’t really save any time, per se, but it’s a more accurate H&P. If a patient comes in and says, “Yeah, I’m on 3 medications… the blue one. And, what’s the red one I take?” If you get those kinds of things, you’re going to be in trouble. With an HIE you’re able to solve that problem and make sure you don’t create any more problems for the patient.

One of the other big bonus things about this is – there’s a lot of drug-seeking behavior out there – and the HIE really nails that. Depending on what kind of physician you are, that can be a consideration in your practice. It takes a lot of the stress out of that, if you pull someone up and say, “Oh, geez, you’ve had Oxycontin from six different providers in the last six months.” And the patient’s presenting with some weird symptoms, you can feel confident about saying this person has drug-seeking behavior, and send them along. They don’t talk a lot about that, but it’s one of the things we’ve seen that is of real value.

I’d really love to see vendors, who are in the position of putting together HIEs, go the opposite direction of traditional – “guess what, now that’s our data; let’s lock it up” – and instead find a way to serve that up and to lend their platforms to actual application developers, to foster more rapid development of high-value applications. Do you see an opportunity to open up access to some of that information so that other, next-in-line developers now don’t have to go through that same integration learning curve?

It’s a really interesting question. I think it’s a great idea. The thing that I struggle with a little bit on all of this is the potential value lit up against all of the privacy and security regulations that are being put in place.

As you know, HIPAA was just re-tightened and we’re going through various audits and making sure that we are compliant with everything for our clients. It would be really great to get some guidance around this. Certainly from a technology perspective, given our architecture, opening up access to all the data in our system to third parties would not be difficult and I think others are in the same boat.  But if I went to one of our clients and said, “Hey, I know you put all your clinical data in our system, wouldn’t it be great if we could expose that data (obviously de-identified) to a bunch of people so they could do some analysis and research on it and learn stuff?”

I think there would be a crater in the ground when their compliance department heard about that. Whereas, if we get the government to say, “Hey, look, as long as you aggregate and de-identify the data this specified way, you can publish this data all you want.” That, I think, would be really powerful.

Other than a handful of new contracts, what would make HIMSS ’10 a successful event for PatientKeeper?

HIMSS 2010 is all about ensuring that community hospitals understand that they have an “an alternative path” to achieving meaningful use – that doesn’t involve ripping and replacing their core IT system. We’re trying to have some fun with this message and you’ll see some brightly colored vehicles around Atlanta offering to provide an alternative path from local hotels to HIMSS. So I’m hoping that we can at least help with HIMSS logistics if nothing else.

Any final thoughts?

I have spent my career in the Healthcare IT space and I can say without question that this is the most exciting and challenging time to be in the industry. We have the opportunity to dramatically expand the scope of IT use in healthcare but also improve its ultimate impact on physicians, nurses, and of course, patients.