Monthly Archives: March 2012

The Interoperability Showcase at HIMSS12

Posted on by

Although well hidden in the back of the basement, the interoperability showcase at HIMSS 2012 was a well attended space.  And that, my friends, saved the vendors adjacent to that location.  I’m not sure anyone would have bothered to find that obscure location without a specific reason to be there.  Over the past three years that we’ve been a part of the interoperability showcase, we’ve seen a much more collaborative approach, a growth in participation, and an atmosphere that harbored follow-up and continuation of the efforts beyond the showcase itself.

More and more vendors have approached us about working together to improve the interoperability needs in the field with their clients after the show.  In the past, vendors had a prototype of their software at the interoperability showcase to prove that they “could” meet the standards and play nice with other vendors.  However, in reality the software deployed in the field was months if not years away from being production ready.  As clients came to the showcase and saw their vendors exchanging data with others, it only increased their frustration when they returned to their offices and found that their ability to exchange data was several upgrades away.  Not only was the timeframe frustrating but the expense of the upgrades was even more insulting.

So people are increasingly coming to view HIMSS Interoperability Showcase and Connectathon as a must-do to test interoperability, a fabricated world, a dry run where engineers and companies have a consequence-free opportunity to test what they’ve got before entering the real world where dollars and reputations are on the line. These important venues give vendors the opportunity to overcome obstacles to the sharing and exchange of patient data which will move them toward achieving meaningful use ultimately changing the nature of patient care.

And to that end, similar to the HIMSS Showcase, ICA has developed ICA Extreme Testing Center, or ICAetc, to provide an ongoing, year-round forum to help vendors achieve sustainable interoperability, save money, and perhaps face, as they lumber forward toward the difficult goals of seamlessly facilitating the sharing of critical patient data. Vendor partners are already participating and more are lining up.  ICAetc is a risk-free environment where EMRs can link to EMRs, work out the bugs, determine limits and horizons, gain a sense of the costs and timing of installing interoperability solution suites.

The results are already impressive. The crowds are gathering. And more are at the door. HIMSS Interoperability Showcase and Connectathon have pointed out the path and hopefully we’ve picked up the scythe and with the help of our industry partners are clearing that path in ways not done before and that will realize better care for all.

HIEs Need Cultural “MegaChange” to Flourish

Posted on by 4 Comments

The alchemy involved in developing and executing successful health information exchange (HIE) is complex.  Technology, policy and specific organizational situations are core components embedded in the success/failure equation that can either help or hinder the creation of a thriving clinical data-sharing network, whether in a hospital, IDN or region.  Because HIE, by definition, requires the cooperation and coordination of multiple groups factions and individuals within an organization, it is important that the various agendas of these groups be identified and addressed.

A recent White Paper published by the Brookings Institution on the governance of HIEs finds that implementation challenges and barriers to successful HIEs are similar to the challenges found in setting up government programs because of the density and complexities intrinsically found in both. “Mission ambiguity, problems of organizational coordination, resource and organizational capacity restraints, political interference, as well as lack of clarity and consensus, limit the ability of policy makers to achieve the desired goals.”[1] Institutional and regional HIEs face these same issues, which are also further complicated by a heavy dose of technology which is at the heart of HIE and what makes it possible.

States and organizations that have implemented HIE are well aware of these challenges and all are in different stages of the throes of wrestling them to the ground to either start-up or improve the distribution and sharing of patient data. For example, Tennessee, an early adopter of HIE, has chosen to build an HIE network on the foundation of former RHIOs (regional health information organizations). This approach has the advantage of embedding interoperability into an existing structure between organizations. The state leverages a “network of networks”[2] methodology of using already accessible networks at the local and regional levels to provide a universal layer of connectivity.

This approach has worked very well for Tennessee, whose HIE is a public-private partnership comprised of physicians, nurses, pharmacists, hospitals, insurers and patients. Other states have had similar, as well as a host of other issues, to deal with.  Among them are 1) governance mechanisms which have a huge effect on implementation. These players typically include hospitals, medical societies, government health departments, universities, physicians and public officials. Others often include payers and unions. The number of players, all with varying agendas, makes implementation a tremendous challenge; 2) consensus on the path forward. With many aspects of healthcare reform being contentious, tensions inevitably arise between local, regional and state organizations which further slow down implementation; 3) the role of the federal government which includes the Direct Program designed to effect simple and secure clinical messaging. While Direct’s goal is to connect many physicians and hospitals, many claim that the program undermines efforts to connect at broader levels.  And demand for Direct protocols, thus far, has been weak. 3) privacy and security continues to complicate HIE performance since data exchange requires permission and consent.  Uncertainty about privacy can greatly impede, if not kill, an exchange network unless sufficient guidance is made explicit. And finally, 4) the elephant in the room is sustainability. With HITECH funding not being eternal, HIEs must plan for ongoing self-sufficiency.  This inevitability is complicated by the current weak economy with states still cutting budgets. Options being considered are membership or subscription fees along with a small “claims tax” which will enable sustainability.

In short, HIEs, while in many ways the clear answer to the kind of connectivity that will ultimately reduce healthcare costs and improve outcomes over the long haul, face daunting challenges. These challenges, taken as a whole, are probably best addressed through a cultural shift, or MegaChange in attitudes that will enable the tackling of these issues broadly in order to get us where we want and need to be: the transformation of healthcare delivery in the U.S.

[1] Kent Weaver, “But Will It Work?: Implementation Analysis to Improve Government Performance,” Issues in Governance Studies, February, 2010, pp. 3-8.

[2]  Darrell M. West and Allan Friedman, “Health Information Exchanges and Megachange”, Governance Studies at Brookings, February 8, 2012, pp 20-21.

Could Interoperability Requirements Spell the End of Client Server PM-EMR Deployments?

Posted on by 1 Comment

As I read this week’s multiple key headlines about Meaningful Use stage 1 delays, the changing of Meaningful Use Stage 2 requirements, ICD10 implementation delays, 5010 implementations and accountable care payment reform modifications, I began to wonder if the EMR/EHR vendors would go through the same evolution as practice management companies did during the deployment of the HIPAA ANSI administrative transactions of the early 2000s. Most of the large, well established practice management (PM) companies with a large legacy installation base saw drastic declines in customers and market share.  The reasons were numerous but the biggest reasons stemmed from the following:

  • Each PM application had multiple versions deployed in the field and there was no easy upgrade path to compliance with these new standards
  • The applications were deployed on several different operating systems further complicating the upgrade process, timing, testing and retrofitting
  • Because of the rapid developments in hardware, the applications were deployed on a variety of hardware platforms

PM software companies established special teams to make changes to software in order to meet the new standards; created special units to upgrade the various versions, operating systems and hardware configurations; and trained support staff in both the software and EDI aspects of the new applications and electronic transmissions.  Although the planning was developed over almost 18 months, changing interpretations of standards, as well as delays in requirement deadlines and procrastination of clients created a support nightmare for established vendors in the market.  Many of the PM companies saw this as a time to re-tool their entire product suite.

Each of these factors led physician practices and hospitals to rethink their vendor of choice for the first time in decades.  Implementation of the new ANSI standards for claims, eligibility and authorization transactions created more turmoil and turnover with the PM industry than any other single event.  Burgeoning new start-up companies introduced SaaS and ASP deployment models of PM applications. These new companies sprung up regionally and began competing robustly with the PM giants of old stealing market share and sending established market names into consolidation and foreclosure.  Many of the household names in the PM business disappeared from the landscape because they failed to anticipate the gravity of this monumental event.

Is the Same on the Horizon for Established EMR Companies?

With the requirement for interoperability to support the Meaningful Use, payment reform and care coordination goals of the federal government and private payers, the same conundrum is now facing established EMR/EHR vendors who deploy their software using a client service methodology.  Changing standards, increasing integrations and growth in health information exchange are requiring these companies to rapidly produce modifications to their software and deploy it through upgrades on various platforms and operating system versions.  Changes like these generally impact older, established players more profoundly because their customers are on older technology and there are simply more customers to upgrade if they are deployed in a decentralized way.

Most of the larger EMR companies in today’s market are the new entrants competing with the established goliaths during the ANSI transition.  Unfortunately, the largest of these organizations deploy their technology on “old school, trusted” deployment methods because their leadership came from previous consolidations within the PM industry.  They did not embrace the ASP and SaaS technology as it wasn’t familiar or proven at the time.  However, I do not believe that client server deployment is sustainable over time because:

  • Maintenance fees will not create the margins necessary for innovative development resulting in SaaS and ASP functionality to overtake client server versions
  • Physician practices generally do not employ hardware, network and systems administration staff capable of more complex upgrades and integration/interoperability system monitoring
  • Physicians will not budget for the capital costs associated with an ever increasing hardware obsolescence cycle
  • Government mandates will continue to accelerate deadlines for vendor upgrade schedules to meet incentives
  • Market forces will continue to increase modifications in EHRs to meet evolving protocols, practice patterns and payment mechanisms – all of which will require EHR functionality modification

ASP and SaaS versions of software are simply much easier to maintain, modify, upgrade and deploy than client server technology which reduces up-front costs and implementation times.  With added security and trust of cloud based technology, client server applications will be left on the ground.  And honestly, would you rather be tethered to the ground with a obsolete hardware anchor or soar into the clouds – especially if soaring costs less and is hassle free?

ICD10 Slow Down - Why such push back from both sides?

Posted on by

Do you remember those ACT, SAT, GMAT and other entrance exams for college?  The Analogy part of those exams was the section where you had to determine “such and such” is to “such and such” as “such and such” is to “blank”.  Well, I would say that ICD10 is to HIPAA administrative transaction as HIPAA administrative transaction is to Y2K.

Preparedness for the New Millennium

Y2K seems like a distant memory.  However, in the years leading up to New Year’s Eve 1999 – their was great anxiety that the digital world was going to come to an end.  The clock ticked 12 and the world didn’t end and we all simply forgot about the time and preparation it took to change the two digit data elements within the world’s computer systems to a place holder of four.  Why did this giant exercise succeed so well?  First of all, there was a date certain.  Secondly, there was a clearly defined scope where no interpretation was necessary.  And finally, it only involved computer programmers – billing or clinical staffs were not required in the process except for the negative testing associated with Y2K upgrades.  Vendors also had years to plan for the upcoming eventand begin installing upgrades early so that testing could occur before the clock struck twelve, and programmers didn’t need special education to understand what the changes needed to be.

Implementing HIPAA Administrative Transactions

HIPAA administrative standards implementation for claims submission, claims status and eligibility verification were much more complicated for the following reasons:

  • The standards were complicated and left many items to the interpretation of readers
  • The data involved payment of claims that impacted the cash flow of the physician office and hospitals
  • There were many players involved in the resultant data: claims processors, coders, billers, clearinghouse personnel, vendor help desks, etc.
  • AND MOST IMPORTANTLY, the government changed the implementation date several times ending up with implementation dates with dependencies.

These factors drastically changed this implementation compared to Y2K.  Each vendor had to implement standards that were often vague and then test these standards with a multitude of players in the clearinghouse, payer and provider markets.  Each participant had interrupted the standards a little differently so clearinghouses, hospital information system vendors and practice management vendors had to modify claims information based on the recipients needs. Clearinghouses and vendors had to modify their legacy systems to capture new data elements and changes in current data elements and then format the data in multiple different ways depending on the payer to whom they were sending claims or eligibility requests.  Medical practices and hospitals had to modify forms, train registration and billing staffs and test with up to 100 different payers to ensure their claims would go through and their remittances would be returned in a timely and useful manner.  And, the vendors and providers had to be able to produce proprietary transactions in addition to the new transactions because the government kept changing dates and exempting types of providers and payers.

ICD10 Implementation

So, why is there such a divide about ICD10?  We must look at the underlying causes of the disagreement to find the answer.  Unlike HIPAA administrative transactions, ICD10 is very definitive in its specifications.  But in many ways, this implementation is very similar:

  • The data involves payment of claims impacting cash flow of the physician office and hospitals
  • There are many players involved in the resultant data: claims processors, coders, billers, clearinghouse personnel, vendor help desks, as well as researchers, physicians, nurses and other clinical staff members
  • AND AGAIN, the government is wavering on the implementation date and will possibly exempt certain types of healthcare providers
  • HOWEVER, the major difference is that this change affects EVERYONE in the healthcare system INCLUDING clinicians

Researchers in the federal government, university healthcare systems, at the Center for Disease control, and others, are licking their lips in anticipation of this new method of getting discrete data with a whole new level of specificity.  Coders are hoping that clinical documentation is sufficient for them to discern a code at the ICD10 level. And physicians are wondering how in the world they’re going to determine a diagnosis at that level of specificity.  Implementing ICD10 is going to be like teaching a man to discern different shades of pink!

Those for moving forward with current dates:

  • Researchers believe that this level of data specificity will increase their ability to determine best practices, identify trends, etc.
  • Payers believe that this level of data will allow them to better reimburse physicians based on acuity
  • Vendors want a specific date so they are not having to support both ICD10s and ICD9s in future releases
  • Clearinghouses and claims processors don’t want to have to support both formats
  • Emerging vendors (those new entrants into EMRs, EHRs and HIS solutions) because they want a jump start on their established competition

Those against moving forward:

  • Physician practices and hospitals who are behind in their education process and are only now realizing the impact on everything they do
  • Vendors with a large legacy installed base who have to retrofit antiquated solutions within their installed base – especially vendors who have bought up smaller competitors and have numerous software solutions with multiple versions of each in the field – because they have an enormous maintenance upgrade task ahead of them with little or no compensation associated with it
  • Payers who are not ready to process claims and understand the impact on additional labor costs until systems are upgraded to automatically process claims, as well as the impact on their provider networks when cash flow is interrupted

ICD10 implementation is an enormous task for the entire healthcare industry.  However, anyone studying paradigm theory will tell you that it is most difficult to create a shift in paradigms when the scope is wide and the timing is varied.  Data certain was easy to accomplish with the Y2K implementation, and everyone knew it could not be delayed. The uncertainty surrounding the implementation of HIPAA administrative transactions caused interruption in cash flow, rework and duplication.  ICD10 appears to be destined for the same result.

ICA’s HIMSS12 Experience

Posted on by

ICA unveiled its new approach for delivering a comprehensive interoperability platform to the healthcare market that is vendor agnostic, rapidly deployable, affordable and easily trained.  The approach consists of five (5) volume modules to meet specific short term needs of the majority of IDNs, hospitals, physician practices and communities while providing a foundation for growth to meet the future complexities of risk bearing organizations.  Each volume is designed to meet the specific needs of healthcare organizations and bring immediate value and return on investment.

The overall solution is designed to assist healthcare provider in:

  • Reduction of re-admissions and emergency department returns
  • Coordinating care transitions
  • Managing the referral process
  • Sharing a common care plan among care team members
  • Developing team based chronic disease management programs
  • Collaborating on other specialized care delivery teams

 

CareAlign® CareExchange – provides a standards-based interoperability platform for the transfer and storage of IHE and Direct Project protocols.  It includes patient matching, provider registry, healthcare internet service provider (HISP) capabilities, and audit functionality for source-to-source transfer of healthcare data.

CareAlign® CareConnect – provides a secure, clinical communication channel for sending, receiving, acknowledging and responding to patient specific information.  It includes the ability to attach both standards-based documents (CCDs, CCRs), as well as non-standard medical documentation (PDFs, Word documents, etc.) in a secure, auditable platform with portal access.  Hospital-based discharge and encounter summaries are also available with automatic notification of the patient’s physician.

CareAlign® CareCollaborate – provides the combined functionality of CareExchange and CareConnect adding additional clinical integration points within the acute and ambulatory settings, as well as additional workflow tools such as a longitudinal view of the patient, work lists, flow sheets and reminders.

CareAlign® CareMeasure – provides an analytical engine to turn clinical data collected through the exchange process into useful data at the point of care.  It includes disease dashboards, bio-surveillance, ad hoc and standard reports through an intuitive, easy-to-use portal.

CareAlign® CareManage – provides additional data feeds from administrative and claims based systems to enhance the risk management capabilities of a healthcare organization.  It allows risk stratification, advanced disease management and population-based targeting capabilities.

In addition, ICA demonstrated the extreme testing center, ICAetc.  ICAetc is a robust IHE and Direct Protocol environment available to vendors across the industry to test end-to-end data transfer transactions on a continual basis free of charge.  The registration, set-up and configuration is Web-based with support from the ICA integration team.

Collaborating with HIT Vendors to Improve Interoperability

Posted on by 1 Comment

People often ask me, why would ICA create a free collaborative environment in which other HIT vendors can practice and test their interoperability capabilities?  The answer is easier than it might first appear – we want to make a difference in healthcare.

Imagine yourself preparing to go to a foreign country for the rest of your life without the ability to communicate in its native language.  Now imagine that someone gives you a book on the language as the only means of preparing for your trip.  You sit in your room day after day looking at words that make little sense to you. Because you aren’t able to speak the words to someone who knows the language, you get no feedback on your progress until you land in the new country.  What do you think your success rate will be to find housing, get something to eat, go to work or attain the other requirements of survival in the short run?

This is the same type of experience HIT vendors are going through now.  They have a set of standards and they assume that they are interpreting them correctly – but they only know if they’re right when it comes time to interact with another HIT vendor in an live environment with one of their customers.  The ICA Extreme Testing Center (ICAetc) is a place where HIT vendors can practice their interoperability skills without limits on the scenario, the type of data being transferred, or with which other vendors are involved in the practice.  It is open to all vendors (yes – even our competitors) because we hear that a lot of HIT vendors are IHE compliant but have trouble implementing IHE in the field.  ICAetc allows these vendors to exchange real data with each other, figure out how they are going to consume the data exchanged, and build better products that work within the framework of care delivery.  We at ICA believe we know how to create interoperable systems that improve healthcare and we are willing to put that knowledge to the test by offering an open testing ground.

The results of this kind of testing bring the entire community of vendors’ game up a notch.  It reduces implementation times for our mutual clients and it makes the overall healthcare delivery system better in the process.  We firmly believe that no one vendor can provide the necessary HIT infrastructure for the entire healthcare marketplace – not now, not in the future.  Every healthcare information technology company must work together if a truly interoperable world within healthcare can exist to deliver higher quality of care to more patients at a reduced cost.