[ Monday, April 21, 2008 ]
PHRs for Spimes: Seattle-based
tech lawyer John Christiansen, a solid contributor to the AHLA's Health Information Technology listserv, posted an interesting observation about personal health records last night on the HIT list:
I Seem to Be a Spime: Why Nobody Wants EHRs and PHRs
How's that for an obscure subject line? Please bear with me; I will
explain.
And if you, like me, have been trying to figure out how to implement
electronic health records (EHRs) and personal health record (PHRs) in the face
of seemingly unrelenting foot-dragging and friction, you might even find this
worth reading.
First off, we need to distinguish EHRs and PHRs from EMRs (electronic
medical records). While there is some confusion and overlap is use of these
terms, in practical terms an EMR is usually the electronic equivalent of the
traditional paper medical record. An EMR, especially in larger organizations, is
not a simple electronic "flat file" transformation of the paper record into
something like a Word or Excel document, but is a system made up of various
applications and databases which store and process patient data.
More to the point, however it is structured an EMR performs well-known,
well established and valued functions for a specific entity. Like a paper
medical record, an EMR is created, owned, and maintained by a specific
healthcare provider (hospital, clinic, physician), and serves the
mission-critical business purposes of that provider (patient care support, legal
risk management, etc.). The provider does have legal obligations to provide
medical record information to patients and other treating providers, but the
core concept is that the EMR provides necessary business and compliance support
to the entity which pays for it and assumes the burdens of maintaining it.
Terminology in this area is fluid and sometimes the same kind of system,
under the same management and serving the same purposes, is called an
EHR.
This seems to be the core concept in the Stark and antikickback
exceptions, for example, though that's not altogether clear. So sometimes an EHR
is an EMR. But not always.
EHRs are also (conceptually and some time in the future, if not typically
in current practice) something more like a community resource for healthcare
organizations and patients, including medical record and other relevant
information on patients from all providers (and other healthcare organizations),
up to and ideally including a lifelong record of all diagnoses and care from all
providers. Sometimes this kind of EHR is said to be owned by the patient, and in
this direction the EHR sometimes becomes indistinguishable from the PHR.
The necessary technologies to implement this kind of system already exist
(albeit with many, many issues to be resolved on matters such as interoperation,
etc., etc.), and the concept is pretty clear: Each of us will some day have a
comprehensive, searchable, online electronic record which documents our health
history and status. Our physical presence will be complemented by and linked to
an online information service, which is used to guide highly customized
decisions about our care - the kinds of products and services we might need or
benefit from, in a medical sense.
In other words, we'll all become spimes.
Science fiction writer-turned-design critic Bruce Sterling (one of the few
people who has a job I want more than the one I have) coined the term "spime" to
mean a sort of hybrid manufactured/network object: "[Spimes] are precisely
located in space and time. They have histories. They are recorded, tracked,
inventoried, and always associated with a story. . . . Spimes have identities,
they are protagonists of a documented process. . . . They are searchable, like
Google. You can think of spimes as being auto-Googling objects."
I'm not sure what, exactly, auto-Googling might be, but here's Sterling's
scenario for how you might encounter a spime, which should give some sense of
how the concept applies to EHRs and PHRs:
"You buy a spime with a credit card. Your account info is embedded in the
transaction, including a special email address set up for your spimes. After the
purchase, a link is sent to you with customer support, relevant product data,
history of ownership, geographies, manufacturing origins, ingredients, recipes
for customization, and bluebook value. The spime is able to update its data in
your database (via radio-frequency ID), to inform you of required service calls,
with appropriate links to service centers. . . . "
This same notion can be extended from manufactured objects to biological
entities with the greatest of ease. Consider what an ideal EHR/PHR could do and
include: Demographic information, details of your physical and mental
conditions, medical history, identification and contact information for your
healthcare providers and health care payors, details of your available health
benefits (and credit history?) - all updated to provide alerts for "service
calls" you should make to physicians and pharmacies, accompanied by useful
"customization" information about treatments for your specific conditions. Add
some family history, maybe some DNA analysis. For some subjects maybe you even
do add physical location information, via embedded RFIDs for institutionalized
or incompetent patients, prisoners, military personnel, or in hospital patient
wristbands, etc. . . .
With the implementation of this kind of system you will be recorded,
tracked, inventoried and associated with the story of your own health history -
you are the protagonist of the documented processes of your interactions with
all the various aspects of the health system you've encountered in your life. So
as far as I can tell this would make you, well, a biological spime - a hybrid
biological/network object.
Sounds scary and pretty complex, no? Yes, actually, and the complexity may
be what keeps it from getting too scary too fast.
Sterling knows that even manufactured spimes take a lot of work, and
distinguishes between those who produce spimes (manufacture the objects and
create the network space for them) and spime "wranglers," a "class of people
willing to hassle with spimes." Spime wranglers have an interesting relationship
to spime-producers: They do a lot of the customization work for them, and
provide them with feedback about how useful and valuable the spime is."
In the PHR world, then, you might consider Microsoft and Google as
spime
producers: They enable the network spaces necessary for information to
be loaded and maintained, and for interaction with the applications needed for
data processing for customized services, etc. But (as Sterling foresees),
loading and maintaining this network resource is going to be a *lot* of work.
Who's going to wrangle your PHR?
Do I wrangle my own PHR as part of me-as-a-spime? This might be an
empowering opportunity for those with the time, training, experience and skills
needed to successfully manage their PHR, but it will be an enormous pain in the
hind end for those who don't. Most people these days take their health care as
something produced by others, over which they have little control, and which
they can only choose to consume (or not). (Interestingly, in the perspective
Sterling brings, this puts most of us a couple of historical steps back from
being able to manage ourselves as spimes.)
Does my physician wrangle my EHR as part of me-as-a-spime? I'm not sure why
she would. She's already overburdened by running her practice and providing care
to my physical self. As to having staff do it, they're busy too, and she doesn't
really have an incentive to pay for and assume the burden of creating a network
object which is a community resource: Her practice gets a small part of the
benefit in return for assuming all the costs? While it may be true that
everyone, including her practice, will be better off once the entire community
resource (i.e., EHRs for everyone) is built, until that happens those who do
assume the spime-wrangling burden are at a competitive disadvantage compared to
those who don't.
The same argument seems to apply to hospitals, health systems, health plans
and so on: Each possible candidate is at a competitive disadvantage if it
assumes the very real burdens of EHR-wrangling. Unlike the EMR, there's no
mission-critical purpose served for any given organization by having this kind
of community/network resource available. It may enable the organization to
provide better care and maybe even get it some savings, some day, but as long as
the EHR/PHR is not the market norm, no market participant is disadvantaged by
its absence.
What I take away from all is that until we reach a point at which some
critical mass of EHR/PHR spimes is established (and positive network effects
take over), somebody is going to have to compensate the spime wranglers.
This, of course, is what physicians say whenever the topic of EHR
implementation is brought up - and the point is, they're not wrong.
Implementing an EMR for their own purposes is a lot of work; implementing
and maintaining an EHR as a common resource for the general good is even more,
and for less relative benefit (for them). And while some consumers might really
like wrangling their own spimes, or find it genuinely beneficial (e.g. for
managing chronic conditions), most probably won't find it as rewarding as doing
many of the other things you can do on the Internet.
Until we can find a way to make the incentives for EHR/PHR wrangling
outweigh the burdens, I'm not sure how the ideal EHR/PHR system gets built
(using only market factors). EMRs, sure; EHRs which are essentially EMRs, sure.
EHRs/PHRs which are a community resource through which each one of us is a
biological spime, I'm not so sure.
Sterling's talk about spimes is at: http://www.boingboing.net/images/blobjects.htm
Bonus aging hippie/geek points if you recognized the source of the
subject line as Buckminster Fuller!
Also posted at my blog, http://informationlawtheoryandpractice.blogspot.com/
John R. Christiansen
Christiansen IT Law
Seattle,
Washington
206.301.9412
Jeff [9:01 AM]
http://www.blogger.com/template-edit.g?blogID=3380636
Blogger: HIPAA Blog - Edit your Template
