This post is my own expression, not an official view of the Society for Participatory Medicine.
Vince Kuraitis and David Kibbe are running an excellent series, “Is HITECH Working?”* In last week’s entry they linked to this slide deck by Wes Rishel and David McCallie of IT consulting firm Gartner. See discussion before watching.
Simple Interop for Healthcare (Wes Rishel)
“Interop” (interoperation, interoperability) is about how your health data will move from one doctor to another. It’s a big deal, because it affects how well doctors can coordinate our care, and in an emergency whether everyone can see what they need to know … to save your life.
Or your mother’s life. Or your child’s.
This is getting increasingly personal to me, because people have started coming to me and talking about the unnecessary death of a family member. I’m starting to see the pain in people’s faces from a premature death, and it’s starting to hurt. But keep ’em coming, because this is real and it needs to be out in the open.
At a policy meeting last winter I heard a tale – perhaps apocryphal, perhaps not:
A man’s having a great time in Las Vegas. He runs out of cash so he goes to the casino’s credit window. They pull up everything about his finances: his income, his credit card balances, which bank has his second mortgage, when he signed on it, everything. They find out what they need to know, make their decision, and give him the cash.
He goes back to the table, hits it big, and falls over with a heart attack. He’s rushed to the emergency room, where they know… nothing about him.
That story corresponds to the “use case” (the scenario) at the bottom of slide 15: “E.D. gets medical records for exceptional case.” When you’re thinking out how a standard will work, you need to think through a bunch of scenarios: who’ll need what information, and how it will get to where it’s needed.
And that gets complicated, which is why so much work is going on in Washington. It’s hard to get this work right, and you usually find strong differences of opinion. For one thing, the people who are already selling systems usually want the new standard to match what they’re doing, and the people who think they can do better want a wide open door to innovation. Understandably, just about everyone wants to maximize their own revenue.
That’s fine in ordinary commerce, such as the print industry where I used to work, where skull-knocking is just plain business. But I assert that in healthcare lives are at stake, and provincial concerns must be subordinated to human survival. Save lives first – then compete.
I think it reprehensible if a vendor wants to withhold medical information from another care provider in an emergency. Reprehensible. And “withhold” includes not actively finding ways to share the information.
Added 10:43am ET My sentiment here applies to providers, as well, who simply don’t want to adopt methods that keep patients safer. Paul Levy, CEO of Beth Israel Deaconess, drove this home persuasively in his speech this month to the hospitalist association, talking about the paradox of these smart people who went into this work to help patients, and who (paradoxically) are the fourth largest public health hazard. (That’s from Brent James of Intermountain Health: death by medical error is the fourth leading public health hazard.)
Why? Resistance to change. This must stop. And we, we all, must stop empowering the excuses. End of addition.
I say, if your top priority isn’t finding more ways to save lives, you ought not to participate in the billions of taxpayer-funded incentives – whose entire purpose is better care.
Lives first – then compete.
And that’s where this slide deck comes in. Its 45 slides reflect a lot of thinking, a lot of work; in the parent blog post author Rishel says he harvested many earlier posts about specific items, bringing it all together in this deck.
This is the first thing I’ve seen that, more or less, makes the issues clear to a lay audience. Here are a few definitions you may need if you’re new to such things:
- Structured data is the computer equivalent of filling out a form: you write “Dave” in the First Name box, “deBronkart” in the Last Name box, “21” for age, 03063 for zip code. Computers can track, summarize, and analyze structured data.
- The opposite is free text: the kind of box in a form where you can write anything you want, and the computer won’t know or care whether it’s your age or your zip code.
- The ultimate unstructured data is a fax. It conveys information, but only when a (falliable) human reads it. The same is true for all unstructured data.
- BUT, unstructured data is better than no data – like the guy who went from casino to E.D.
- The ultimate, the goal, is when the sending computer uses structured data and the receiving one does too.
- Imagine if airlines had to work with unstructured data, with fax-like blobs of text. Structured data is information; unstructured blobs convey information only when read.
- The trick, the difficult part, is that today everyone’s system stores the structured data differently, so it won’t transmit same-to-same.
- And THAT is where we get into hairy details that can take forever to resolve.
- Plus, the more complicated the details are, the harder everyone has to work, to write software that complies. That slows things down and raises costs for developers. And that raises costs for the physicians who pay for the systems.
- The opposite is free text: the kind of box in a form where you can write anything you want, and the computer won’t know or care whether it’s your age or your zip code.
- MIME is the data format tht systems use today to send email. It can be used to send anything, not just email; its great advantage is that it’s as simple and common (already in use today!) as sending and receiving email. These slides propose using MIME as the way for one system to send your record to another one.
- Simple! “Simple interoperation,” as the title says.
- Requires little or no software development or testing.
- Free text can be sent as the body of an email.
- Structured data, including PDFs or images, can be sent as attachments.
Particular slides to note:
- Slide 7: What simple interop can do (handoffs of care to another provider, lab data (already in fields)
- Slides 9 mentions PHRs, noting “patient uses PHR to collect their own data from multiple sources and disburse it as they see fit. (Yes!)
- Slide 13: The use case of a primary doc referring you to a specialist – how does your information travel? Considers cases where either doctor does not have a structured data system yet.
- Slide 17 gives several more use cases for patient engagement.
- 28: Minimum functions for PHRs (Personal Health Records): receive information from mulitple providers; attach it to the right person; deliver info to others as directed by the patient.
Don’t worry if some of these slides are unclear; you’ll still get the picture: even for a lay reader they explain the pragmatic issues we’re facing, and they describe a clear and pragmatic pathway to encourage users to adopt, i.e. to start using these systems.
There are people, with good intent, who don’t like simple subsets; who want to figure out a complete specification and then implement it all at once. But that’s old-school, it takes forever, and it creates a very long “time to value” outcome. (i.e., it takes forever before anyone earns back what they invested.) We don’t have time for that. People are being harmed unnecessarily. (Plus, as I said, it’s technically risky to try that approach.)
I reject the argument that any vendor has a right to put higher priority on its commercial interests than on saving more lives by transporting vital information between clinicians who need it to do healthcare.
Save lives first – then compete. I believe simple interop is a good, practical, expedient step forward. Thanks to Gartner for the slides and thanks to David Kibbe and Vince Kuraitis including them in their excellent series. (More on that seies shortly.)
* HITECH: Health Information Technology for Economic and Clinical Health act. HITECH is part of the 2009 ARRA economic stimulus bill
I absolutely agree that lives should come first, and that patients should be in control of their own information.
I also understand (but don’t agree with) the tech companies wanting to make a grab at what’s going to be a huge system.
What I *don’t* understand is why there’s even any discussion as to using Mime, since it’s so readily available everywhere. Right now, emails can be sent to fax machines for printing, and the email third party systems (Outlook, etc.) are already either in place or can be quickly developed because developers are familiar with the data types. Written reports could easily be scanned and attached. Diagnostic codes have already been developed for the insurance industry and could be mined from reports and input. Xrays, mammograms, CT’s, stress tests are already automated.
OTHER than greediness, what’s to argue about?
Annie
Well, Annie, there’s plain old foot-dragging. And there’s no single finger of blame at vendors – I’m going to edit my post because my wording didn’t make clear that foot-dragging providers are pressuring HHS not to move so fast.
Have a look at the ad (PDF) the American Hospital Association has been running, combined with a letter writing campaign. “Strict requirements… constrain hospitals… policy ignores upfront cost, time, and logistical challenges.”
Well, in my testimony to the Meaningful Use workgroup Tuesday, I said “There comes a time when you have to take the car keys away from the people who haven’t been getting the job done.”
I like the response of the National Partnership for Women and Families, one of the strongest groups I’ve found in Washington. They gathered a strong coalition of 52 groups and corporations (including us, the Society for Participatory Medicine) to co-sign a strongly worded letter.
On his blog, Ted Eytan described it as Oh No You Don’t – the day consumers rejected norms around HIT.
Okay, here’s what I added:
Added 10:43am ET My sentiment here applies to providers, as well, who simply don’t want to adopt methods that keep patients safer. Paul Levy, CEO of Beth Israel Deaconess, drove this home persuasively in his speech this month to the hospitalist association, talking about the paradox of these smart people who went into this work to help patients, and who (paradoxically) are the fourth largest public health hazard. (That’s from Brent James of Intermountain Health: death by medical error is the fourth leading public health hazard.)
Why? Resistance to change. This must stop. And we, we all, must stop empowering the excuses. End of addition.
Completely agree.
Although I worry that my bouncing around to various specialists (trying to find THE one) could work against me if everyone could see it.
M
I like this. It addresses one major point I’ve been evangelizing (unsuccessfully) for a long time: focus on the meta-process. The majority of the deck addresses what we need, not what they want to give us. The conversation can be about whether that is really what we need. We need to scale and formalize this meta-process. When the internet was developed, they had an awesome meta-process: everything new was submitted as an RFC (request for comments) document. The very name suggests that it is not just a proposal, it is the beginning of a conversation. E-mail was defined in RFC 822. In years as an early-internet sysadmin, I’ve referred back to that many times. MIME was defined in RFC-1521. Health IT has lots of people proposing solutions, but rarely is there an open approach to thinking about how to discuss these proposals. There’s nothing remotely like the careful, measured process for how we study therapies.
Most of HIT is done in a top-down approach. Dave’s Google Health fiasco based on a medical record built from billing codes was created in a top-down approach. Top-down approaches to solutions frighten me: “From this day forward, you will all do X!” We need more providers and developers to work together to make good systems that improve care, and fewer government or industry groups putting constraints on those solutions.
While we can ask people to use IT systems to improve care, we should not ask HIT to decrease its cost. If you want HIT to succeed, it should increase provider revenue. (My actual position is that it should meaningfully increase primary care revenue with a goal of decreasing specialist and hospital costs.) Why? The cost of care is driven by economics: every player is attempting to maximize their own profits. Imagine if someone came into your business and said, “Change how you do your business. Hire consultants, run training, and build new IT technology. At the end of this, your business will make less money.” (Even if the stimulus check covers implementation, it won’t cover lost revenue.) Don’t change technology to contain healthcare costs, change the economics of care.
While I suspect that a number of people have thought it, Pete, your post is the most lucid expression I’ve seen yet of the contrast between the development process that’s been engaged in HIT, and the process that drove (drives) the development of standards in the internet environment.
Dave’s crisp expression of urgency and priority – “Save lives first, then compete” – is a tremendously powerful way to trigger motivation and focus. But, as you suggest, what’s also needed is an equally crisp expression of the process – like “RFC”.
One of the most exciting aspects of the NHIN Direct initiative is its reflection of the methods and principles of internet standards development, contrasted with the more structured (or, perhaps, “more strictured”) top-down, comprehensive, government-led HIT development initiatives.
Dave,
“Save lives first, then compete”
You nailed it.
If you ever get tired or bored of the ePatient route, you have a great future in copy writing :)
“Simple interoperability” is not just a theory…it’s being done.
Arien Malec has taken a leave from Relay Health to assist in building NHIN-Direct http://www.nhindirect.org. NHIN-Direct is being built off the principles developed by Wes Rischel of Gartner and David McCallie of Cerner.
It’s happening! Now!
> If you ever get tired or bored of the ePatient route,
> you have a great future in copy writing
What makes you think there I’m not already doing that?? I’m the memes guy around here…
– Patient is not a third person word
– Your time will come
– Gimme my damn data …
My job is to take all this abstract crap and put it in sticky phrases that latch onto people’s minds, so their attitudes shift. (Seriously.) When you’re out to move behavior, it can be handy to have a marketing guy on the team.:)
And, seriously Vince, the analysis you guys did on this truly empowers me to slap a sticky phrase on it. Good team.
Are you saying that NHIN-Direct uses MIME to transfer data?
Is there an encryption layer? I get so lost in the claims and counterclaims about whether security is required.
MIME is just a container protocol — you can put anything in it. People typically used the Content-type header (RFC 1049) to identify message types, and the content-type “application/pgp- encrypted” has been used since the mid 1990’s to put encrypted messages in MIME messages. Just as you can put (binary) JPEGs into the MIME container, one can stick ASCII-encoded encrypted data in, too. This is both the benefit and the limitation of MIME. I’d probably opt for XML over MIME because of the stronger structure and more elegant nesting.
Understood about MIME. (My workgroup used it 5+ yrs ago to bundle mixed content for high quality print jobs.) My question about encryption was whether NHIN-Direct or anything else privacy-related *specifies* a particular type of encryption as part of the exchange rules.
Dave- NHIN and IHE seem to support generic public key cryptography with data exchange through TLS (updated SSL) protocol which supports any algorithm. The only explicit cryptographic choice is the specification of the X.509 “chain of trust” protocol for public key verification.
Hi Dave,
Very good thread. I agree with your passion and your desire, and I want this for myself and my family too. You speak of a very important scenario:
“That story corresponds to the “use case” (the scenario) at the bottom of slide 15: “E.D. gets medical records for exceptional case.” When you’re thinking out how a standard will work, you need to think through a bunch of scenarios: who’ll need what information, and how it will get to where it’s needed.”
Everyone would agree that lives should be saved. However, you then refer to the “simple interoperability” which is largely associated with the recently formed NHIN Direct project and is considering delivery mechanisms like e-mail. But the E.R. use case is almost by definition not a direct referral but an unexpected emergency, and is not one of the user stories being addressed by NHIN Direct currently (see http://nhindirect.org/User+Stories). Don’t get me wrong: they ARE addressing important user stories, just not the one you used as an example. The E.R. needs to get the patient data from possibly several other providers who had no idea that the emergency was going to occur. A lot of the NHIN and HIE efforts, plus much previous work in standards bodies like HITSP, specifically addressed such use cases which involved finding and pulling data from other providers, and had a variety of standards to support it including BOTH structured and unstructured data which are both necessary as you say. Wes had a caveat in his March 14th blog about NHIN Direct vs HIEs that stated re NHIN Direct: “However, it provides clear limits in supporting care transitions in that the sender has to know to whom the patient is transitioning – or the receiver has to make a special request for information that must be manually approved by the sender.”
The fact is, many organizations (vendors and providers) have “found ways” to share information through existing standards. I hope that we will deploy the standards that were already developed through consensus, while still innovating and finding ways to address each use case efficiently and simply.
So, in summary, I’m just pointing out that the Vegas E.R. case is not a simple one and may not lend itself so easily to the simple interop cases currently being analyzed in NHIN Direct. The ER may not know even whom to ask for the patient’s info (unless this is a very proactive patient carrying an electronic copy of his PHR in his pocket, or emergency instructions on how to break the glass and access his cloud-based PHR).
Regards, and keep up the good work.
Thanks David – good to meet you. Just caught me on my way out. I’ll see if I can attract any comments from people with spare opinions. :)
Thanks, Dave. BTW, re NHIN Direct and ER use cases, see http://nhindirect.org/message/view/Patient+arrives+in+Emergency+Department/22651771 for a statement on why they marked it “out of scope” and also for some interesting stats from CDC and other research that address the frequency of the ER case that you talked about.
Regards,
David Tao