On the heels of the HIMSS 2009 conference in Chicago last week, a report about inaccuracies in Google Health are shedding light on the age old fact of “considering the source”. The original source of the data is one of the most important things when seeding any system.
Dave deBronkar, a kidney cancer survivor (full article), found that after data had been imported in to Google Health it said his cancer “…had spread to either his brain or spine…” which was not the truth.
As Bob Evans from Information Week (full article) explains:
Google Health users are finding stunning inaccuracies in medical records imported from primary-care physicians and hospitals because Google takes some information from insurance billing records that use broad and imprecise codes to describe patient treatment.The codes that Bob Evans is referring to are what is known as ICD-9 codes and they are used in the billing context to indicate the symptom of the diagnosis for the treatment rendered.
When coding the diagnosis for a diagnostic study, one will first code the finding and then the symptom (or complaint) from the patient. If the finding is negative, then only the symptom (or complaint) will be coded. In this case, if the data were to be imported into Google Health or any other Personal Health Record (PHR) it would show inaccurate information for this patient.
For example, a patient comes into the ER and complains of pain in the chest. A chest x-ray would be performed. If the result of the x-ray is found to be normal, the ICD-9 code for chest pain would be used for reimbursement purposes. In this case, this is a symptom not a finding. If this data was imported into a PHR it would be misleading.
The chest pain could have been caused by a case of excessive “flatulence” which would not have been captured in the PHR, if only billing data was used.
In addition, as John Chilmark points out ICD-9 is “limited” (full article).
Problem is, claims data is based on limited code sets (ICD-9) that physicians use for reimbursement. This can lead to inaccurate entries/codes as physicians struggle to fit a diagnosis to a given code or possibly prescribe a drug for off-label use, or even “game” the reimbursement system. Either way, end result is an inaccurate picture of the consumer’s health.
If claims data is bad, what is the best way to seed a PHR? In my opinion, there is no existing source we can take data from to create a baseline for a PHR. Billing data is currently being used because it is already electronic (meaning cheap), and insurance companies want to make sure they continue to wedge themselves between the doctor and the patient.
The first step in building an accurate electronic view of a person’s health is to strengthen the direct relationship between the doctor and the patient. This goal can be catalyzed through the use of Internet communication/networking tools. Simultaneously, we need to create open systems that are interoperable, which are built on existing standards. Together through direct communication and sharing the data population of PHR systems will be at the point where they only have accurate and meaningful data.