« A lot going on today | Main | Interesting take on standards development »

06/12/2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Adrian Gropper MD

Somewhere along the way, we seem to have lost the perspective of patients and patient-centered health records - once again.

Rather than seeing this as a tweak of the specifications, I think we should revisit the reason for NHIN Direct in the first place and ask, from a regulatory perspective, how policy can promote value in health care and health care services.

Arien Malec

Adrian -- while I could see an argument that one approach is innovation centric and another approach is tradition centric, I'm not sure I see the argument that one approach is patient-centric, and another is not. Could you explain?

Tom Munnecke

For what it's worth, I used SMTP in designing the internal interface structure for VA VistA and DoD's CHCS systems. I didn't have a committee structure like this to deal with, I just called Jon Postel and asked him to register VA.GOV for me. But I think that the basic SMTP structure has a lot to offer, with some tweaks, of course.

I like Adrian's comment, "I think we should revisit the reason for NHIN Direct in the first place and ask, from a regulatory perspective, how policy can promote value in health care and health care services."

I guess I would revisit this issue with the question, "How do we use IT to create the maximum level of meaningful communication in health care?" Part of this communication is indeed the medical record, but a whole lot of health care is person-to-person communication. In fact, gobbling up precious clinical encounter time with the doc frantically typing on his keyboard instead of looking at and talking to the patient might decrease this communication.

This perspective would lead to a health care "space" model, rather than "let's integrate the systems" model. We've seen the benefits of this kind of thinking in the web. Look at what Tim Berners-Lee had to say about his design of the web:

"What was often difficult for people to understand about the
design of the web was that there was nothing else beyond URLs, HTTP, and HTML. There was no central computer "controlling" the web, no single network on which these protocols worked, not even an organization anywhere that "ran" the Web. The web was not a physical "thing" that existed in a certain "place." It was a "space" in which information could exist.”

The last thing that people who owned the hierarchical, proprietary, pay-per-minute networks of the time (AOL, Prodigy, CompuServe) wanted was this free linking of information across this open "space." But Tim had the foresight to base it all on TCP/IP and blew off the proprietary influences at the time.

I guess the real question is, are we trying to pave the cowpaths in the current perversely incentivized health care system, or are we looking at IT as a technology to improve our health?

Brian Behlendorf

What's interesting to me in this conversation is the degree to which metaphors fail us. TimBL might have said there was nothing beyond URLs, HTTP, and HTML, yet the IHE stack (leaving aside the organization or its standards process) shares much in common with Semantic Web concepts of meaningfully structured data. The Web couldn't have mandated it everywhere on day 1, it had to go through a phase of being lots of dumb barely scrapeable HTML and still is. The question is, how much of "worse is better" should be tolerated when real people's lives are at stake?

A crucial question that exemplifies this tension for me is the patientID issue. In XDR, messages must be associated with a patient, and only one patient, denoted by a patientID. This patientID can be a value that is only meaningful to the sender; the recipient can simply note it and then associate that message with future messages bearing the same patientID from the same sender. I can see how this simple construct can save the clinicians time that would otherwise have to be spent saying "Gee, I wonder which Patient Joe Smith this data is associated with", and the inevitable errors that would follow. If NHIN Direct messages are simply emails sent with standard-issue mail clients, with no other guarantee that there is going to be a patientID header in either the headers or the body of the content in a reliable way, then we have created a significant burden for the clinic. Is that an acceptable trade-off? Those who have been down this path didn't add a patientID requirement because they felt the protocol wasn't complicated enough. They added it because they felt the cost of patient-matching errors in health records transmission was much greater than the extra client-side cost of associating that message with a specific patient.

Since there are transactions anticipated in NHIN Direct that are not patient specific, like reporting aggregated data to public health authorities, it's reasonable to push against patientID as a requirement in some settings. But it seems like the kind of situation where a little bit of foresight on the part of NHIN Direct implementors could save real money and lives - and at least be worth the discussion.

Ahier

I think is important to remember one of the primary purposes of this project. We must find a way for small practices and rural and underserved providers to participate in exchange. We already have made some great progress on NHIN Connect and Exchange and I would encourage those who wish to continue working on IHE to focus in that area. My strong feeling is that we should use a combination of REST with SMTP ~ how exactly that will look is what we need to figure out this week.

Lee Jones

I believe the premise that IHE is inherently incapable of satisfying the "simple" mantra is just false. We (MedAllies) are a small company. We have implemented the IHE stack. We served as a HISP for all the IHE demo cases. We deal with small practices. And even if it were overly complex, as some seem to find it, there is value in the extensibility and synergy it brings. My suggestion is as it was before. Let's let REST and SOAP coexist, make the HISP requirements to support both (or evolve toward that over time), and allow edges to support whatever they want. We can manage parallel implementations of such a small number of protocol standards, and I'm sure learn a lot from both thrusts. However, this is *only* viable by keeping the IHE path in the mix somehow as a hedge against the greenfield development for this type of HIE (the verb) using the other protocols.

David Tao

I may have more to say after reading the various posts on this subject (Sean's, Wes's, etc.). In many debates of this sort, it's often a matter of "which criteria do you value most highly?" as you said, Arien. To some, adoption by existing commercial EHR vendors counts highly, and to others it doesn't (and may even be a negative in their eyes). Anyway, Arien, I appreciate your attempts to keep a balanced perspective. I also appreciate Microsoft's hospitality. I see Sean's arguments as very important considerations for the would-be HISPs of the world -- it does need to be simple and economical to "stand up a stack" whatever it turns out to be. I think that the locus of the debate has probably shifted more toward the ability of HISPs to thrive business-wise, since the end-user experience (i.e., what the doctor sees) is generally agreed by all to be e-mail or simple web page (even in the IHE XDR-backbone-with-flexible-edge proposal). At least on the need for the user experience to be as simple as (or to BE) e-mail, I think we have agreement among all the teams!

Thanks,

David

Anon

Interesting factoid, RIM uses SMTP for BlackBerry Messenger communications...

The comments to this entry are closed.