I am all for standards. The more we define and codify the practice of medicine, the better and more interoperable our EHRs become. But a standard, for the sake of a standard, takes us backwards.
I believe the writers of the Final Rule that defined Meaningful Use of an EHR took us backwards when they specified two different standards for coding the problem list (SNOMED and ICD-9). Most organizations appear to be using ICD-9 to code the problem list. I believe that this is because SNOMED is way too complicated and there is no decent implementation reference.
But ICD-9 coding of problem lists does not make sense. Firstly, this country is in the process of migrating away from ICD-9 codes. Why make that process more laborious by creating one more conversion? Let’s skate to where the puck will be.
More importantly, ICD-9 codes do not describe problems in the hospital. ICD-9 codes are medical billing codes. Sure, they are based on a disease classification system, but problems are not always analgous with a disease or condition. For example, an important problem to note during a hospital stay is that the patient is “at risk for fall” based on a fall assessment. What is the ICD-9 code for this?
ICD-9 codes collected as part of creating the problem list will not provide any additional data beyond the ICD-9 codes that are already abstracted as part of the billing process. So, this pseudo-standard does not provide any new insights. Furthermore, I don’t believe this codification will do anything to improve the interoperability between providers and systems. In the end this is work for work’s sake. Busy work keeps us from implementing the rest of meaningful use that has true benefit to the patient and those that pay for care.
At least this is the way I see it. Am I missing something?
Candid CIO 
Actually ICD 9 is not that bad of a framework for most medical scenarios. It’s weak when you have symptoms without diagnoses but really if you were trying to create a codified problem list of discrete entries what other currently accepted and at least marginally familiar system would you use? In our hospital EHR implementations the problem is really much more about getting everyone to use a shared patient centric cross encounter patient problem list and much less about the nomenclature used (although many wish they could just use free text, but that’s not useful for many reasons). Getting providers to move away from enumerating the problem list in their transcription and therefore eschewing the EHR problem list as redudant is one of the major challenges as is getting them to recognize the ‘community’ nature of that problem list – that they have an ethical duty to update and correct the list as they care for the patient. I don’t see any simple solution or new miracle nomenclature on the horizon so we have to use what is available today. ICD 9 and ICD 10 are still more logical to end users than SNOMED.
It was the United States that took a disease classification system and made it into a reimbursement methodology. One of the major reasons we are migrating to ICD-10 is to allow more specific capture of critical and meaningful information. We are way behind the rest of the world in the world in the migration to ICD-10 and primarily because of how we tied it to reimbursement in this country making the transition extremely burdensome. I agree that we should focus on only one classification system.
If standardization for the sake of standarization takes us backwards then why is Ministry IT so bent on standarizing everything. Case in point – the standardized desk top. By treating everyone the same, you tie the hands of those that use their system for more than just basic microsoft business applications. Those who actually have higher function software on their system to do their job are now hindered by IT’s standarization decission. To make matters worse, you need to spend many hours justifying your need to IT. I understand the need to simplify things, but you also need to understand that there are people who don’t fit into a nice little mold and IT has to have the flexibility to recognize those individuals and adapt.
John, it may feel like you are justifying requests to IT, but IT is coordinating a process prescribed by senior management. Ministry senior management chooses the applications that we support and they are the ones that make decisions about where IT team members need to spend their time. In general they are rightly directing us to spend our time in a way that produces the most results for our patients and the sustainabilitiy of the system. The reality is that there is no way to meet every person’s unique needs. I know because I too have unique tactical needs that could be supported by additional software, but I understand the organization’s strategic direction.
The reality is that it is impossible to support 14,000 employees with 14,000 different desktop configurations. The standard desktop computer is a very complex computing environment. Our standard applications require a very specific combination of technologies. When IT’s customers are allowed to change that configuration it results in an unsupportable number of help desk calls; support tech dispatches; and interruptions to employee productivity. Locking down the PC is a fairly common approach for large organizations. Gartner has ben recomending this as an IT best practice for years, citing that it reduces the cost of each PC by $2,400 per year: http://bigfatfinanceblog.com/2009/11/09/lock-down-the-desktop-to-save-money/
As I mentioned recent blog post, increasingly desktop software is being replaced by web-based services. I don’t know your unique need, but you may want to see if someone is providing it as a web service that you can access using your browser. We are happy to help you search out web serivecs or explore other options to meet your need. You can contact your Customer Service Manager, or you can call me any time at 715-204-4224.
I really do understand the need for standardizing as much as possible. When you have a large majority that only needs a core software group and basic computer skills it makes perfect sense. However there is a small percentage of very tech savvy people that the model will not work for and I hope that there is a plan to to provide help for those people. If there is, it isn’t very apparent.
Back in 08′ you posted
” I have always embraced our tech savvy employees. They are my people. When others were writing Internet Access policies that restricted employees use to “business-related sites,” we were encouraging people to join the Internet revolution.
I realize that IT cannot meet every possible need. With tools like QuickBase we can unleash our tech savvy employees to meet their own needs, while keeping them in a sandbox.”
Do you still support this or is this a thing of the past?
I appreciate your understanding. Yes, I still firmly believe that we need to create an environment that attracts tech savvy employees. The things that I described in the post you reference are still things that we do today. We have a very liberal Internet access policy, because I know tech savvy employees use the Internet to do things they used to do in person and on the phone. I want an employee that is paid hourly to have the convenience of messaging the kids on their break. I want exempt employees to do online banking when working late. We also provide a QuickBase so employees can create web-based applications to meet unfilled needs by IT. So far our employees have created over 7,000 such databases.
The one place where we have decided where we can’t afford to have a liberal policy is the desktop. I held out far longer than other organizations our size. I truly wanted employees to install any software that would meet their needs, that is the convenience that I would want. But, the evidence is overwhelming. Employee installed software creates thousands of support desk calls every year because the software will conflict with IT-supported applications; and people will assume IT is responsible for providing support for any software installed on their computer. Frankly, the tech savvy employees created more phone calls than others. This would make a good blog post, since I have lots of data and anecdotal evidence.
John, as I recently posted, I think that 80% of desktop software has an online equivalent. I am not sure of your specific need, but I hope you can find an online service that will fill the gap for you.
John, I will take this as a challenge to think about other ways to support and encourage tech-savvy employees. Thanks for your feedback and your service to our patients and your efforts.
The code you are looking for is V15.88
You may actually have this backward. ICD-9 are disease codes, NOT billing codes. Most billing systems in the US, like MS-DRGs for hospital billing of Medicare services, jam the ICD-9 system into a billing system. There is no better system to denote a problem list.
To address your example, how do you determine someone is at risk of a fall? It’s the diseases and problems they have, all of which have ICD-9 codes. Or this one V code: V15.88 History of fall, At risk for falling. You can look this up in an online coding tool like SpeedECoder, http://www.speedecoder.com.
We are two full years out from the ICD-10 conversion so requiring ICD-9 is completely inline with HIPAA coding set requirements and decades of practice.
But it’s worse than I9 and/or SNOMED (which will get there but that’s another post/comment): you can pass meaningful use with any old problem codes (or allergy code). Dr Seuss can pass meaningful use: http://www.caregraf.com/blog/dr-seuss-translates-nothing-at-all
Meaningful use 1 is meaningless, for machine-processing anyway. To enable decision-support/reasoning on records, an information exchange standard would have to specify one scheme – SNOMED – and a primitive subset of that, at that.