Just a few years ago, the industry saw most vendors touting their support for meaningful use. Today, that focus is slowly shifting to the "ready for ACO" mentality. But unlike meaningful use, said Shahid Shah, software analyst and author of the blog, The Health IT Guy, the technology required for ACOs isn't as well defined, leaving most vendors' claims "untestable."

"Don’t be fooled into buying health IT applications that promote an 'ACO in a box' solution," said Shah. "There is no such technology, and there really can’t be. ACOs are not a technology problem; they are a business model problem first, and until the business side has decided how it will identify savings – and share those savings – any purchase will likely be useless.

"The EHR systems and IT required for MU is a quite different from what will be required for ACOs," Shah continued. "It will be nowhere as easy for existing legacy EHRs to simply retool their current platforms, like they did for MU."

With that said, Shah outlines nine ways future EHRs need to support ACOs.

1. Sophisticated patient relationship management (PRM). According to Shah, today's EHRs are more document management systems, rather than sophisticated, customer/patient relationship management systems. "For them to be really useful in ACO environments, they will need to support outreach, communication, patient engagement, and similar features we're more accustomed to seeing, from marketing automation systems than transactional systems."

2. Getting data from your systems through business intelligence and reporting. Meaningful use in its first stage, said Shah, is all about getting data into your systems, all with little outward sharing. "Data collection is something we've been doing for decades – even before MU came along, we knew how to build systems that can collect and store data bases," he said. What most people have never been good at though, he continued, is getting data out of a system in a useful way. "Now with ACOs, business intelligence reporting, and analytics across dozens of disparate systems is a real requirement," said Shah. "Today we all have problems getting data out from a single departmental EHR to help with billing inquiries and clinical decisions support." With ACOs, he said, you not only have to pull data and tie it together with departmental and local systems in your organization, but outside your organization as well.

[See also: EHR Association pushes back against reporting requirements.]

3. Data integration for analytics capabilities. "This doesn't mean we toss in HL7 routers and hope for the best," said Shah. Most IT environments have the ability to send messages from one system to another. "That's called 'transferring' data, which we've been doing for decades," he said. "Integrating data, though, means much more – the ability to store and understand information in data marts, data warehouses, and clinical data stores and repositories from a variety of sources." Having an EHR, he added, doesn't mean you're ready for data integration; instead, you need tools "beyond what health IT firms provide," he said. "Traditional data integration vendors should be getting most of your attention here, as opposed to healthcare-specific."

4.Granular clinical data sharing. The ability to integrate data into your own system is one thing, said Shah, but granularly sharing that same data across ambulatory practices, lab partners, and other shared providers is going to require HIEs of varying levels of sophistication. "Early on, you might even need to try to bypass the HIEs and create your own local exchange using the Direct Project to make sure you're in control." Using the Direct Project to transfer secure data between partners — while building your data marts and warehouses outside traditional EHRs – will be "your best architecture bet," he said.

Continued on the next page.