Health 2.0, Computable Data Exchange, and The Sparse Information Model, by David C. Kibbe, MD MBA

One of the processes that Health 2.0 will certainly come to depend upon for its growth and utility is that of computable data exchange.  What I mean is this:  how do we help our customers/users get their basic health information; how do they upload it to our applications; and how do we store it for them in such a way that it can be re-used, re-connected, and re-purposed?  An important corollary of such a process specification involves answering this question: what do we mean by "basic health information" ?  I'm going to suggest that we employ what I'll call a Sparse Information Model to help solve these problems. The purpose of this blog is to get a discussion going about this process.

After all, we don't want to re-create the experience of the frustratingly infamous clip board and its paper forms, which must be filled out over and over again at the doctor's office or hospital. Health 2.0 applications and web sites don't want to force users to type in their own health information repeatedly, do they?  No, much better would  to collect the important health data and information one time,  and store it in a manner that can be used many times. To do this all Health 2.0 applications must know precisely how to import, read, and interpret the data when presented with them. This might be the "glue" that holds numerous Health 2.0 partners together, allowing many different kinds of sites and applications  -- search, social media, decision support tools, pricing sites, etc. -- to make the user's experience of sharing his or her health data seamless and easy, across those domains. 

One of the stumbling blocks that people encounter as they approach this effort can be expressed something like this:  "How can I possibly handle all of that health information and data about myself, or my customers?  Health care information is voluminous, complex, and highly coded.  Who can make that mass of data digestible or manageable?  It's a god awful hair-ball!"  (To use Esther Dyson's term for health care.)

I'm sure it seemed a similar challenge when the first search engines approached the masses of data on the web, and thought about how to index them or make searches efficient.   

The solution, or at least part of it, is to understand something quite counter-intuitive:  that to be useful, the data stored electronically about a person's health and health care experiences doesn't necessarily have to be large or complex or encoded.  Very large numbers of potentially useful Health2.0 transactions and processes could be done using only a minimal set of data about a person's health, provided the data were electronically formatted in a quite standardized fashion and interpretable by large numbers of applications.  In fact, what is most desirable most of the time is a way to keep the health data payload small, not large!  Separating the signal from the noise is very important.  Sparse information is sometimes very good, not always bad.

I know:  this flies in the face of most conventional wisdom about PHRs and health care informatics, which places great value on keeping comprehensive stores of longitudinal data from all kinds of health data sources on hand, preferably in a master patient indexed master data repository that is a highly normalized relational database with hundreds of tables and thousands of joins.    Forgive me for saying this, but the conventional wisdom here is wrong.   Such a model of health information may be useful for very large enterprises, but it is not at all helpful as the basis of a personal health information infrastructure at this point in time.

What I perceive that Health2.0 needs to adopt is a sparse information model for health and wellness.  We need a way to unambiguously compute using a small but highly relevant core set of personal data, such as one's demographics (age, sex, etc.), insurance information, diagnoses and problems, medications list, allergies, and immunizations, etc.   We should be thinking of the many low and medium value things that can be done with a sparse information model in Health2.0, rather than the much fewer very high value things that require oodles of health data. 

Here are some of those low to medium value deliverables that could be attained for millions of people with just a small amount of personal data using web services:

- provide me with basic preventive health and wellness advice for a person of my age, sex, and with the problems that I have in my list, generating questions for me to think about or answer along the way.

- provide me with the prices of the medications I take at 5-10 different pharmacies or mail order firms, on a monthly basis, with mapping directions and co-pay information to help me find directions and know what my insurance will pay. 

- suggest generic brands that I could substitute for the name brand medications I take, or which have been prescribed, and update this list when new generics come on the market via email notices.

- check my medications and allergies for possible side effects, and check any symptoms I'm having against the known symptoms caused by these medications, while also connecting me to people who share the same symptoms.

- tell me something meaningful about the doctors and hospitals who are taking new patients who have my kinds of problems, e.g. office hours, whether or not they use email, where they learned their craft, and what 15-20 people like me with my problems or issues say about them.

To answer these and many other similar kinds of questions about health and wellness in a personalized manner does not require large data sets.  To be truly user-friendly, however, the applications that wish to offer these kinds of health informational services do need a small and highly structured data set that allows the web services to come to the person, and not the other way around.  Adoption of Health2.0 will be slow as molasses if we force people to type in their data each time they use a different Health2.0 application or visit a new website.

The Continuity of Care Record,CCR, standard is an XML schema that is based on a sparse information model and is highly suitable for the task of creating a personalized small data set of relevant health data for the individual, and for transporting those data between Health2.0 websites and services such that the individual need not hand enter the data repeatedly.

In subsequent writings (depending on the responses to this entry, as I don't want to discuss this issue if the community feels it is irrelevant) I'll address some of the initiatives that are using the CCR standard towards this goal, and also the barriers and challenges that remain to be solved before Health2.0 can take full advantage of the promise and power of the CCR standard.   (FD, the CCR standard is an open, royalty-free standard developed under the auspices of the standards development organization ASTM International's E31 Technical Committee.)

David Kibbe

Comments

[Hamish MacDonald]

Dr. Kibbe,

Small and personalized data sets are definitely important for the progression of Health 2.0, for the reasons you outline in your blog.
Please continue commenting.

Cheers,
Hamish MacDonald

[Stef Verlinden, MD]

Dear David,

I completely agree with your observations/suggestions. As far as standards for 'semantic/ level 4' interoperability go, I suggest you to look further than the CCR standard alone.
A standard for true semantic/ level 4 interoperability, that can be used in systems that are both scalable and maintainable, which is also broadly used, is quite a challenge. Despite many standardization efforts almost nobody has addressed let alone solved this. Most efforts choose for a partial/ local solution. That alone will never work since broad acceptance of a standard that delivers is key semantic/ level 4 interoperability.
Since almost 20 year a small but dedicated group and nowadays fast expanding group of people have been working on a broadly usable open standard for EHR and PHR systems. Since they realized that broad acceptance is key, they not only developed a standard but also brought this up for international standardization. These efforts have resulted in a double CEN and ISO norm (CEN/ISO 13606). Therefore it is now de facto the world wide standard for semantic/level 4 semantic interoperability, scalability and maintainability. More information can be found on www.openehr.org.
We're developing a PHR system based on this standard. In my opinion conformation to the CEN/ISO 13606 standard is crucial to deliver true patient/citizen empowerment (see also my blog at vivici.wordpress.com)

[David C. Kibbe, MD MBA]

Dear Stef and Hamish: Thanks for your positive comments. I'm aware of the CEN/ISO 13606 standard, but would like to discuss it with you, Stef. My email is kibbedavid@mac.com , and we could take the discussion off blog. Perhaps there is an opportunity to get the ASTM CCR standard and CEN/ISO 13606 communities talking together.

One thing I see of value about the CCR standard for the Health2.0 community is that it is not as highly constrained, and is open for input and changes from this community, based on market-driven needs, in a fast emerging sector of this industry. It is not over-designed and remains quite flexible, in other words. I know that to engineers this is sometimes anathema, but personally I like the idea of invention as collaboration, rather than dictate from a standards body.

Kind regards, DCK

[jd]

David,

I'd really like to hear your insights on the issue of uniquely identifying patients. Whether we have a sparse information model or a more complete/complex one, none of this is going to work unless there is an automated way for data from multiple systems to converge into one record. There is now an NPI for physicians, but what about patients? It seems something like a social security number is out of the question, so what are we going to do in it's absence?

Of all the large problems we have ahead in developing computable data exchanges (privacy, data ownership, business models for data exchange, operational data standards, etc.), it seems that this issue ranks right up there. Any thoughts on how we can resolve it?

[gjudd]

Here's hoping Dr. Kibbe's 'contrarian' observations on the value of beginning with simple health care info interchange win broad acceptance quickly.

I'd urge him & others to consider that even his insistence that "To be truly user-friendly, however, the applications that wish to offer these kinds of health informational services do need a small and highly structured data set " may overstate the case.

Need "structured data set" be modified with "highly"? I'm not even sure how a "highly" structured set would differ from a merely structured one; or how extensive the structure he alludes to must be, to be useful to senders and/or receivers of information.

More structured than my email account? If so, how much more?

Looking forward to learning....

[Steve Beller, PhD]

David,

I understand the value of a sparse info model and minimal data set, but I contend that having a lifetime of comprehensive, detailed clinical data about signs, symptoms, risk factors, treatment particulars, and outcomes on every patient is necessary if we truly want to change the current healthcare system in profound ways, as I discuss at this link.

And you asked an excellent question: "How do we help our customers/users get their basic health information; how do they upload it to our applications; and how do we store it for them in such a way that it can be re-used, re-connected, and re-purposed?"

An elegant solution is a decentralized (peer-to-peer) system that sends copious amounts of health-related data in encrypted flat files (e.g., CSV format) that use formatting templates to present the data in customized dynamic (interactive) reports. This low-cost, highly efficient solution works in conjunction with any data stores. And it is compatible with XML, although it is much less "verbose" and consumes much lower resources (i.e., much less processing power and network bandwidth). Furthermore, the data in the flat file are "live," which means the data are readily available for aggregation and computation (e.g., to determine significant trends and associations), and can be repurposed and used by other applications without complex transformation.

I discuss this radical innovation at this link. I welcome any feedback.

Steve Beller, PhD
Wellness Wiki
Curing Healthcare Blog.

[Maude]

i am not particullary stupid on an it-level. not very advanced or intelligent either. just a simple doctor who surfs on the internet, try to use scientific sources (like cochrane, embase, medline) to improve my clinical work , i have been following this health 2.0 through bmj, and several weblogs, in short rather representative for a big bulck of gp's in western europe. and i can not understand a f*ck what this 2.0 is about. Wake me up, when somebody can explain health 2.0, in 20 lines plain english. oh yes, and something else: if the big pharmaceutical companies are involved, i will not trust it and hence not use it. If even intelligent people like former editors Marcia Angell (NEJM) and Richard Smith (BMJ) admit how they can be misguided, how the more us, simple gp's.

[Paul Biondich]

While not letting perfect get in the way of pretty good, I'd contend that once information is stored in a coarse way, it's rather difficult to codify or structure later.

There are consequences to storing data coarsely. Inability to drive decision support, inability to derive measures of quality, and complexities in aggregating data in a flowsheet for easy viewing by clinicians.

The topic of this article seems somewhat misplaced, in that I'd contend that it's not either coarse or sturctured... it's actually a nice synergy between coded and free text, based upon understanding how you'll ultimately use those data.

[Martin Jensen]

Dr. K is onto something here. If we're really going to let consumers drive their own healthcare, we shouldn't be suprised that they'll want to go somewhere. They're not going to want to manage a bunch of records -- even the really sick ones. I pulled some of this analysis together in reference to the dominant PHR paradigms on my blog at http://blog.hittransition.com/2007/11/phr-as-a-verb-a.html

Marty