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

Leave a Reply

Your email address will not be published. Required fields are marked *