Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!
The American Medical Association (AMA) passed a resolution at its 2011 Interim Meeting mandating the group to "vigorously work to stop the implementation of ICD-10 and to reduce its unnecessary and significant burdens on the practice of medicine.” The resolution that the AMA will "do everything possible to let the physicians of America know that the AMA is fighting to repeal the onerous ICD-10 requirements on their behalf" continues.
Strong language, AMA, but the ICD-10 train has already left the station. And we have seen this sort of talk before —there is a sense of déjà vu here.
Remember the successful efforts of the AMA and other organizations to delay the original ICD- 10 implementation date of October 2011? That’s the day CMS originally targeted for mandatory ICD-10 adoption for physicians, hospitals, and payers.
The AMA’s point of contention about the October 2011 date was that physicians were not given sufficient time to upgrade all systems and then provide training and education. They also cited the cost would be significant and the expense of the implementation should be spread out over a longer timeline. The Bush administration allowed a delay until October 1, 2013 — two additional years.
After the announcement of the initial delay, a seemingly satisfied AMA led the way in providing resources for physician practices to transition to ICD-10 within the agreed-upon timeline.
So why the change of heart now?
Organizations have already invested significant resources in ICD-10 adoption. No one is arguing that the implementation is challenging and costly, especially on the heels of Meaningful Use and other healthcare reform measures. But the AMA seems to have forgotten that they helped architect (and then eventually approved) the October 2013 delay.
Also, the AMA or, more importantly, the physicians within the association, needs to realize that the benefits of ICD-10 far outweigh the costs of implementation.
ICD-9 is outdated and no longer effective. The numbering system cannot support the addition of the new codes. With time, attempts to find codes are increasingly difficult since some are being placed wherever there is a free space in the sequencing.
The rest of the world uses ICD-10. In fact, the rest of the world is getting ready to move to ICD-11. The US needs to not only catch up, we need to realize that sharing and comparing data with other countries yields better quality of care with increased clinical efficiency and improved outcomes.
The additional codes provided by ICD-10 afford another degree of specificity that will reduce claims processing costs by reducing recurrent requests for information during the billing process. Of course, there is the flip side: documentation will continue to be a challenge. For example, a physician may know specific information about a patient but not write it down, even though the additional documentation will help with outcome assessments and quality of care indicators. It’s up to the provider, but wouldn’t they want to show how their care provides exceptional patient outcomes?
Let’s proceed with some caution. Do not let this latest AMA decision stop or even slow the implementation of ICD- 10 within your organization. It seems that a better solution would be for the AMA to get back on the train and determine how to they can improve the transition process rather than try to derail it.
Change is never easy, but let’s not be in the same position another two years down the road and have déjà vu “all over again.”
M. Christine Kalish, MBA, CMPE is an executive consultant with Beacon Partners.
A Response to Vince’s Epic Article
This is a counterpoint to Vince Ciotti’s Readers Write article, The Other Side of Epic.
I usually don’t comment, but I definitely had to say something here. Epic — like everything else — has its problems. However, Vince’s claim that Siemens Soarian or Cerner Millenium has "equal or better" functionality is totally laughable. I’ve worked with both and neither comes close.
Vince states that Epic is not an integrated solution because it lacks general ledger and payroll functionality. Cerner and Siemens (in Soarian) don’t, either. Siemens had GL/AP/payroll in their older SMS products, but they aren’t offering it any more and are selling SAP instead.
Furthermore, GL and payroll are probably the least of your worries. If you get Siemens, you’ll have to interface disparate clinical, patient financial, and pharmacy systems as well as a bunch of departmental systems, each of which have different platform, database, and hardware requirements. You’ll also have to deal with all the third-party components required to make the system work, some of which have to be purchased separately. Epic, on the other hand, truly is an integrated system with a single database used by all modules (as is Cerner Millennium.)
Speaking of databases, why does Vince call InterSystems Cache’ a "proprietary" database? It is proprietary, but so is Oracle (used by Cerner Millenium) and MS SQL (used by Siemens Soarian Clinical, Financial, and Scheduling). Incidentally, Siemens Pharmacy, which you "have to" get if you want a fully functional Soarian Clinical system, also uses the InterSystems Cache’ that Vince seems to dislike.
Some of Epic’s departmental modules are arguably weak, but the same can be said of Siemens and Cerner as well as most other vendors. That is the price you pay for an integrated solution.
There is talk that Epic doesn’t play well with other systems. I do not believe that to be true, either. In addition to your everyday HL7 interfaces, Epic has a module for real-time query/retrieve relationships with non-Epic EMRs. Cerner has equivalent functionality, but Siemens does not (although I assume they must be working on something or buying another bolt-on product).
Epic, which has the best documentation I’ve ever seen, provides extensive documentation of their architecture, database, and APIs. As a last resort, you could dive into that. Obviously, the server-side MUMPS code is visible to customers since it’s interpreted, but I was stunned to find out that they also provide the client-side source code to customers as well, obviously with legal restrictions on how it can be used.
I am not sure where Vince got the idea that Epic is less customizable than Siemens. Siemens Invision is very customizable, but Siemens Soarian definitely is not.
For the record, I have no ties to any vendor. I can honestly say that I have never seen a product or company that impresses me like Epic and I am definitely not prone to brainwashing. I also want to say that I really enjoy (most of) Vince’s articles. This last article bewilders me, though, because it would seem to suggest that he is either biased or misinformed. I am disappointed.