Ken Willett

Healthcare IT, integration, and making patient care better

Monthly Archives: February 2012

ICD-10 and Historical Data

There are a lot of conversations these days about coding standards and upgrading to newer, more sophisticated standards. The recent delay of ICD-10 implementation was welcomed by some and criticized by others; but one topic I haven’t heard much about is what is supposed to happen to historical data.

EHRs are new to many providers, but others have ten or fifteen years, or more, of historical data on their patients in their EHR. Typically this data includes problem lists, which are typically coded with ICD-9 diagnosis codes. Diagnosis codes are also sent with diagnostic test or medication orders to justify them, so these codes are part of the patient’s order history. So what happens to this historical data at the ICD-10 conversion deadline?

One approach would be to go through the entire patient population and update their problem lists. Unfortunately, since there isn’t a unique mapping from each ICD-9 code to an ICD-10 code, this method couldn’t be completely automated. And the EHR generally prohibits tampering with signed historical data anyway.

Alternatively, the provider could wait till the next patient visit, then recode (or have their staff recode) the problem list for each incoming patient. This seems to be what most providers were planning, and the productivity impact on each visit accounts for some of the resistance coming via the AMA. But besides the staff time, it means that for a very long time the EHR will contain a mix of ICD-9 and ICD-10 historical data. So how does that impact the ability to report meaningfully across the patient population?

There is a third option: use ICD-10 codes only where required (such as for billing) while leaving the EHR problem list coded with ICD-9 codes. But this just prolongs the problem; eventually all that data needs to be upgraded.

Tools from the EHR vendors to assist with the recoding would help; but realistically we are in for a long period of having to support both diagnosis code sets.

The Coming Coding Collision

There have been a couple of interesting federal program announcements in the past few weeks. One was that the Center for Medicare/Medicaid Services (CMS) would postpone its deadline for ICD-10 conversion, which was supposed to happen October 2013. This was apparently due to considerable pressure from the AMA, concerned with the impact on its members of a change in coding methods. ICD-10 is a replacement for ICD-9; both are used to code diagnoses and problem lists. ICD-10 is used in at least a limited way in other parts of the world; ICD-9 is the current standard in the U.S.

The second announcement was the Phase 2 Meaningful Use guidelines of the Office of the National Coordinator of Healthcare IT (ONC). The proposed rules were announced at HIMSS in Las Vegas last week. I have looked at the proposed rules and they don’t mention specific coding schemes (the Phase 1 rules didn’t either); but some observers report that the ONC will require SNOMED coding for problem lists in EHRs, and perhaps LOINC codes for lab results.

A common complaint from critics of the Phase 1 guidelines was that, without some sort of coding standards, data interoperability is impossible. But, does having multiple overlapping coding schemes really help? In the area of diagnostic orders and results (including labs), the current practice is to use lab-specific codes for both orders and results. CPT codes are used for billing purposes for orders, but they aren’t specific enough to completely identify the test. ICD-9 codes are used for justifying diagnoses in the order.

LOINC codes, which are specific to laboratory tests, would be a significant improvement for coding lab result values, but they have not been widely adopted by labs. LOINC also has a code set for lab orders but no standard for diagnosis codes. ICD-9, ICD-10, and SNOMED all have coding methods for diagnoses; ICD-10 also has a coding method for orders. Without some work to bring these proposals into alignment, vendors and providers may be faced with conflicting requirements to code the same information in multiple ways.

Part of this issue stems from conflicting requirements, and it may be that these can’t really be reconciled. Labs need to know exactly what test is being ordered. Payers need to know not only the test but its justification. Clinical Decision Support systems need to map orders to patient conditions to guide order selection. Quality measurement systems need to be able to aggregate data from multiple sources using standard codes for results and diagnoses. And providers need the ability to record diagnosis, testing and treatment decisions without an undue burden. Each coding system seems to address some, but not all of these requirements. Government mandates may improve things; or they may just add to the confusion.

Ignis at HIMSS

Overall, HIMSS was a good experience for us this year. Pat Wolfram and I met with investors, possible partners, and customers, and a number of new opportunities emerged. And we had a chance to meet our new salesperson, Jim Sheils, face to face. Since he is on the East Coast it would have been a while, probably, before we met.

Our operating mode for the past few years has been for a couple of us to travel to HIMSS and meet with as many people as possible. Some of that is on the exhibit floor; a lot is over lunch or dinner, or huddled in a corner in the hall. One problem with HIMSS is that there aren’t enough quiet places to sit and talk.

There was something new at HIMSS this year (or at least, I wasn’t aware of it before): an area for vendors with smaller booths that are somewhat grouped into “Knowledge Centers”. By having several vendors with related interests near each other, and a little space for presentations, the idea is to be able to attract people from the main exhibit floor. There seemed to be a lot going on down there (it was a lower level area at the Sands).

I think this is something we might potentially be interested in. The cost is much more modest, and you don’t need 50 staff people at the event to make sure that people walking by have someone to talk to. Please give us your thoughts as to whether this is a good idea.
Next year is New Orleans. I’ve never been there, so that should be interesting. Hopefully not during Mardi Gras, though.

Random Thoughts from HIMSS

I’m back home now after one of the roughest airline flights in a long time (about 15 minutes of non-seatbelt time). Trade shows in Las Vegas are always pretty strange. Some thoughts:

  • It didn’t occur to me till I got back that Tuesday of HIMSS was Mardi Gras. I was even staying at Harrahs, which has sort of a Carnivale theme, and my room was in the Mardi Gras tower. But since Las Vegas is crazy all the time, Mardi Gras doesn’t mean much.
  • It was interesting walking around the show floor, and comparing companies’ booths to what I know of the company. Small companies trying to look like they are bigger than they are; old-time companies trying to be young and hip; and non-healthcare companies trying to look like healthcare experts.
  • There’s a species of bird, I don’t recall the name, where the male builds an elaborate nest with a lot of shiny and colorful bits of material, then struts back and forth in front trying to attract attention. The females tour around the various nests looking for mates. It’s almost exactly like a trade show.
  • Unlike most of the booths, which are designed to try to welcome you in, the Epic booth had a wall almost all the way around it. I don’t know if that metaphor was consciously ironic or not.

Ignis at the HIMSS Venture Fair

This week we participated in the HIMSS Venture Fair, where a small number of companies seeking partners or investors presented their companies. We were fortunate to be selected, and it was a great experience. First, each company had eight minutes to present. Which meant the presentation had to be extremely tight. Secondly, it wasn’t a product presentation (which I have more experience with) but selling the company: its vision, management team, growth potential, etc.

It was interesting that not all the presenting companies are actually looking for venture funding. Some are established companies looking for growth capital. Some are looking for partners, or to be acquired. Sizes ranged from “almost ready to demo the product” to $50 million per year in sales.

It was interesting to try to pick out the investors from the entrepreneurs. My original guess was that the people who looked comfortable in their neckties were the investors. But that stereotype turned out not to be entirely accurate.

Our main objectives in doing this were to get some visibility, and to get validation that our story and our strategy make sense, and I believe we were successful in both of those. And now that my presentation is behind me, I can relax a bit.

Sending Lab Reports Directly To Patients

If you asked most people what HIPAA is all about, most would point at its provisions for privacy of personal health information. But another core aspect of HIPAA is the ability of a patient to obtain information from their own medical record. This applies to all providers treating the patient, but until now has had an exception for medical laboratories. That may change this year as HHS considers a policy to require labs to provide test results to patients.

Part of the reason for this is untangling the interdependencies between HIPAA, federal CLIA regulations for labs, and a variety of state laws that may require, prohibit, or restrict labs from providing reports directly to patients. The proposed regulations will place labs under the same requirements as other providers, and they will be required to provide a patient with a lab report on request.

There are significant challenges to doing this well. First, the lab generally has no direct relationship with the patient, so assuring that the request is legitimate will be difficult. Second, lab reports are designed to be as informative as possible to a medical provider, but much of the information would be meaningless or misleading to the patient without guidance from their physician. For example, a lab value identified as “abnormal” by the lab doesn’t take into account the patient’s history, their current treatment plan, and other factors which the physician would use to determine whether that value was actually of concern.

A patient should have the right to obtain lab reports directly from their lab; but for better patient care it makes more sense for this information to come from their provider, with the appropriate guidance about what it means to this particular patient in their situation. Providers need tools to allow them to quickly construct a simple but informative report for the patient, and they can assure that requests for this information are authentic.

A Short Rant On Password Security

Several decades ago, as the Unix operating system came into wider use, a serious security flaw emerged.  All usernames and passwords were stored in a file called passwd, which could be read by any user. Within the file, the passwords were “hashed”, making them unreadable. But it was possible to take the passwd file and, by trying thousands of words, or millions of combinations of characters as possible passwords, a persistent attacker could find a password that matched a hashed value. Having done that, they could use the username and password of another user to access the system.

Since that time, many password policies have been implemented to make brute force attacks more difficult: longer passwords, prohibiting use of English words, and requiring a mix of characters. These policies don’t take into account the fact that, in most current systems, brute force password attacks are impossible anyway.

Any reasonable network or web application that accepts username/password authentication can simply limit the number of attempts the user is allowed. If the user gets, say, 3 tries and then has to wait five minutes to try again, there is no way to attempt the huge number of password guesses. Username/password information sent over the Internet is generally already encrypted by SSL.

Password policies that try to prevent brute force attacks, along with others that require changing passwords frequently, have actually weakened security, for the simple reason that users are less likely to be able to remember their required passwords. They are more likely to write them on a Post-it note “hidden” under their keyboard, or to put the password in a text file on their desktop.

Security studies have shown that most attacks on systems are perpetrated by insiders: those with physical access to the system, not anonymous Internet hackers. Most attacks involve passwords that were “discovered” rather than “guessed”; that is, a user is tricked into giving up the password, or malware installed on a computer captures the typing of the password, or the Post-it note is found. Long, complicated passwords do nothing to prevent this type of attack.

Whenever I am required to create or change a complicated password for another application, I reflect on the fact that such provisions make IT people feel more secure, without actually improving security.