Home » Readers Write » Currently Reading:

Readers Write 11/21/11

November 21, 2011 Readers Write 13 Comments

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!

ICD-10 Déjà Vu
By M. Christine Kalish, MBA, CMPE

11-21-2011 6-29-17 PM

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
By QuietOne

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.



HIStalk Featured Sponsors

     

Currently there are "13 comments" on this Article:

  1. Epic may have real time query tools for non-Epic EHRs, but that must be the least used code in their entire system. I have _never_, _ever_ seen a hospital or health system pushing Epic on the locals allow them to use their own tools and still be part of the bigger group. I can think of a dozen places around the country right now where it’s Epic’s way or the highway. Even my own doc was force-fed Epic+GE by the hospital…until they learned that the GE+Epic connection didn’t really connect. [I’m in Vermont – if they can’t get GE and Epic to talk 5 miles from a GE mothership, what does that tell you?]

    Now, perhaps the local hospital is making the decision in each of these cases…but Occam’s Razor tells me that it’s a little more simple that that.

  2. AMA and ICD-10
    I think it is important to understand how AMA makes policy. It isn’t AMA members at all. It is delegates from virtually every state and specialty society in the USA and medical students and residents.
    The policy making part of the AMA is an organization of all MD organizations in the country. So, that policy really represents the consensus opinion of those organizations representing virtually every physician in the country.
    The AMA doesn’t control its policy decsions. Other organizations do that.

    We don’t all agree with that policy but we sure do need the AMA.
    On ICD-10, I agree that the train has left the station and the AMA will waist its resources if it truely tries to stop it from going any further. I am not convinced that it will be this vast improvement over ICD 9 but only time will tell. I hope it isn’t as intrusive in the workflow as meaningful use has become.

  3. Epic operability. This is one I’ve always been curious about.. Can anyone give specific examples of Epic’s inoperability? .. Is it things like the vendor publishes one HL7 spec & others can take it or leave it? Is it that they are not responsive to another vendor who is trying make an interface work? What eactly?

  4. Re- Quietone & Epic…
    Q said Epic is functionaly better…I am with Vince on this one. At best Epic may be marginally better, but not by much. And I say that becasue I know of many areas – some major like LIS -where they are very deficient. Q even states this. On the other hand there are other functions where Epic is better than say Sorian or Cerner. The net net is if you look across all functions, they are maybe marginally better at best.

    The problem I see is very few hospitals take all the requirements into full consideration. In my experience EMR decisions tend to get steamrolled by a few strong /outspoken sponsors in the facility, and then the QuietOnes get taken for the ride!

    And as far as a proprietary dB I would measure that by looking at how many off the shelf tools are available to you to get at your data and does the vendor give you all (or almost all) the schema so you know what to look for? My view is there are far more tools available for Oracle & MS-SQL…way more than Cache.

  5. I agree with Vendor Neutral…Epic is not friendly in the sandbox, at least right now…they are dragging their feet in getting interfaces completed for systems especially those that are competitive to Epic modules. They have definitely become more rigid. Epic has been more of a hindrance than a help with interoperabiltiy and I have been a big Epic supporter through the years.

  6. Re: Epic functionality versus other vendors… Keep in mind that much of Epic’s functionality is dictated by the organizations themselves. We heard it repeatedly at UGM: When you upgrade Epic, take the new features. It’s pretty common for end users to say “Epic doesn’t do x, y or z” when really, Epic does it and has done it for years – the organization just hasn’t turned those features on. If anything, Epic should probably push organizations harder to take the initial hit of turning on new features, which will better serve all of us in the long run. (…or would HIStalk readers amplify their “It’s Epic’s way or the highway” mantra?)

  7. I see Epic alot. I’m not a competitor of theirs, but operate somewhat in the same circles, and talk to their client C-Suites often.

    I think what people often like about Epic is that it is their way or the highway. This crap is hard to do. If you can remove the variable of customization and variation, you probably increase the odds of success (as defined by being on schedule and not having cost overruns) from 25% to 50%. That is material.

    When I think broadly, though, about Epic, I think they will eventually become the old, and other companies will represent the new. They already have a classic innovators dilemma. Why become more flexible or give up any of their profits when they have a cash cow? They can have a few thousand happy employees and part owners in Madison for a long, long time. That is hard to give up. Epic is a big company. They took their risk long ago and are now being paid the dividends handsomely. They won’t be the one to stick their neck out again — it will be another company, as Epic once did.

    Judy may be a liberal Democrat, but she is a capitalist through and through. Her money making machine works, and history would suggest that when a company hits that enviable stage, their reflex is to milk the cash cow vs. drive openness and cooperation in the industry.

  8. I think someone in the AMA took a good look at ICD-10’s PCS system and saw its a substantial threat to CPT and all the licensing fees it collects. That is the only reason for this late – hold the horses – last ditch effort to stop the transition. Otherwise, why didn’t it throw its hat in with BCBS while BCBS spent millions trying to stop the implementation in the early part of the decade? The USA is extremely behind here…the rest of the world is already looking to ICD-11.

    As for Joe’s comment on intrusiveness to the workflow, as someone who has been coding with it for a year now, the system is really not that much different than ICD-9. We’ve found physicians already document most of what they need to, albeit not always in the places coders have been looking. Specificity will change the paper charge ticket to be sure, but almost all practices are using some sort of EMR now anyway, correct? Seems that the transition can be made extremely smooth if your vendor is up and running on time.

    Point being-the AMA’s lateness with this one is ridiculous and harmful. The rest of the world already uses ICD-10 and its required for reporting to the WHO. Healthcare systems like the Cleveland Clinic are moving to transition to ICD-10 early for data collection reasons. The USA has to recode our WHO data to ICD-10 to report it. Why aren’t more people questioning the AMA’s motive with this? They have the only codeset that requires exorbitant fees to use. They have a lot to lose if CPT is ever dropped from HIPAA.

    Excellent article Ms. Kalish!

  9. “Judy may be a liberal Democrat, but she is a capitalist through and through. Her money making machine works, and history would suggest that when a company hits that enviable stage, their reflex is to milk the cash cow vs. drive openness and cooperation in the industry.”

    Got that right. She may be a liberal Democrat, but runs Epic in a way which would make a 19th century factory owner blush.

  10. @QuietOne,
    Re: “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…”

    No, your comparison is invalid.

    Cache is a derivative of a proprietary hierarchical MUMPS database. Oracle, MS SQL Server, DB2 (the big three, there are numerous smaller players) are derived from relational database theory as defined by E.F. Codd.

    What many people don’t understand is that in databases, there is relational and there is everything that came before relational. Pre-relational databases had numerous different data models, little standardization, and no impartial way to evaluate correct versus incorrect design decisions.

    Relational databases have their underpinnings in mathematical set theory. This has proven to be a powerful tool to understand and implement schema designs.

    What does this mean in practice? Relational databases all have underlying concepts in common. Third party report writers and tools are commonplace. Interconnect standards are well established. There is a widely implemented data access language. Core database theory is entirely portable which means employee skills are transferrable.

    Each commercial implementation of a relational database has some proprietary elements, it’s true. However in the broad sweep they are far more alike than different.

    Cache markets itself as a “post-relational” database. That is mostly marketing bumpf. There were several object-oriented databases (CA Jasmine was one) and not one was a true commercial success.

    The latest trend in databases are “Big Data” systems. These are simplified databases that relax the ACID rules. They have advantages when working with massive datasets… but their weaknesses are often precisely that they don’t standardize the things that relational databases standardized (even if imperfectly).







Text Ads


RECENT COMMENTS

  1. I think Disingenuous is confused (or simply not aware of how it has been architected). How control of Epic is…

  2. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  3. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  4. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  5. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.