Thoughts on protocol choices
fred trotter
I wanted to post my personal take on the protocol decisions,
after yesterdays calls. You can find them here:
http://www.fredtrotter.com/2010/06/09/what-protocol-for-nhin-direct/
I think my "scoring" is pretty fair on the items that I care
about, but the "totals" are somewhat misleading, given that I am only
totaling what I care about. If someone could point me towards a whole
area of evaluation that I should care about, is useful to
differentiate the protocols, but did not include please tell me and I
will re-score my sheet.
Would love to have links for other comments on the protocol
choice issues.
-FT
--
Fred Trotter
http://www.fredtrotter.com
David Tao
Thanks for your open assessment and caveats that you weight most
heavily things that are important to you (don't we all?). I only have
a few "nit picks" but on some significant points. I ask that fact
substantiate assertions. The "big incumbent EHR vendors" statement has
been made by many. Last I checked, participants in NHIN Direct itself
are mostly not "little guys" though I believe they sincerely have the
little guy at heart. Google (w. REST)??? Microsoft (with SMTP)??? The
particular EHR vendors participating in NHIN Direct? Not little.
To say that just because a group like EHRA supports something that
means it must be wrong is backward logic. It should be a meritocracy,
and there should not "guilt by association." The fact is that most
SDOs and industry efforts including NHIN Direct tend to have most of
the work done by reps from larger organizations -- vendors, government
agencies, large providers -- simply because those organizations have
more people and can assign some to such efforts, whereas the smaller
organizations can't. This isn't because of any evil intent on the part
of those organizations (including NHIN Direct), but if we look at our
own participants, and especially who's active, there are lots of
bigger organizations involved, and I hope that the public doesn't just
dismiss it just because Microsoft, Google, IBM, Oracle, Sun, et al
were active in it.
As for IHE, I published a list of who supports XDS, and the list is
public and transparent and updated after each Connectathon.
http://nhindirect.org/message/view/Concrete+Model+Comparison/24993643
People can judge for themselves by looking at the list who is big and
who is not, but I think it's not accurate to make a sweeping
generalization about "big" and "incumbent."
You're right that a bridge is needed (you said "bride" but I thought
that was a humorous Freudian slip since we're talking communication
here :-). I've also heard the AOL/Compuserve analogy before: it just
doesn't fit. IHE may not be everyone's favorite choice, but it is
based on industry standards and an open-consensus process, unlike
proprietary networks of old. Another statement you made was that IHE
makes "EHR integration" a requirement, whereas the demo yesterday
clearly showed participation of non-EHRs (e.g., e-mail clients) at the
edges. The team acknowledged that there is room for negotiation on
what is truly "minimal" (including the patient ID) metadata, and I
think that NHIN Direct has done well to stimulate that discussion. I
do credit all the teams with "moving toward the middle" and trying to
be inclusive of other protocols.
I just pointed out a few items that stood out to me, and I'm not
saying I disagree with all of your assessment. In participating in the
blogosphere over recent months, I read plenty of flaming opinions and
assumptions about the motivations of others, totally unsubstantiated
by facts; I appreciate (in contrast) your effort to be balanced. But
there were a few "charged words" and generalizations/inferences about
"big" etc., that I felt I should comment on.
Thanks,
David
fred trotter
Thanks for the discussion...
> To say that just because a group like EHRA supports something that
> means it must be wrong is backward logic. It should be a meritocracy,
> and there should not "guilt by association."
A little known fact about EHRA is that it is not an "EHR Vendor
association at all" but rather a "proprietary EHR vendor association".
Take a quick look at the application to join. You will find that to
participate in EHRA you must have a proprietary EHR system. Open
Source EHR companies are excluded by default. I am the director of
Liberty Health Software Foundation which is intended to be an
alternative trade organization that is friendly to Open Source EHR
companies. For a brief moment, I had considered seeing if I could
wrangle together consensus on which protocol LibertyHSF should support
by speaking the CEO's of the top Open Source EHR companies (Medsphere,
ClearHealth, DSS, et al), but then I realized that I would never be
able to pin them down to a position because they would view the whole
notion that an aggregation of interests like LibertyHSF or EHRA could
take a "position" on a purely technical question like this as de facto
invalid. If they wanted to participate, they would be.
So my point here is that insofar as EHRA is merely an aggregation of
interests it is not relevant. The fact that EHRA would think that
participation at that level is valid is, in my mind, a further
indication that the organization does not "get" Open Source.
Ironically, this is precisely the way that Microsoft -does- get open
source, or at least as far as this project goes. (not a sentence I
thought I would ever write). This is evidenced by Sean's and the other
Microsoft people's contributions to NHIN Direct. Sean has credibility
with me because I respect his contributions to this project. Microsoft
gets some credit for paying him to be here, but I respect Sean, not
Microsoft. When Sean makes a technical case, I respect his positions
because I have found his opinions to match my own so often. I can use
the fact that I trust him as a proxy for investigating technical
issues myself. (That does not help too much this time, because other
people I respect are recommending other implementations... one of the
reasons I decided to investigate and comment on this decision)
So to sum up. Open Source calculus shows that Microsoft will have lots
of influence on NHIN Direct because Sean and his crew have a history
of being right. EHRA has no influence absent someone from EHRA who has
been right alot. The fact that EHRA "represents" lots of companies is
irrelevant and a distraction to the real question of "who has the best
technology idea".
>
> As for IHE, I published a list of who supports XDS, and the list is
> public and transparent and updated after each Connectathon.
> http://nhindirect.org/message/view/Concrete+Model+Comparison/24993643
> People can judge for themselves by looking at the list who is big and
> who is not, but I think it's not accurate to make a sweeping
> generalization about "big" and "incumbent."
Obviously there are lots of organizations that are backing IHE. There
are lots of good Open Source projects there now too. Hell I am one of
the people who "supports IHE". But I am backing IHE for NHIN
Exchange/CONNECT, and I am not yet convinced that it makes sense for
NHIN Direct. I am convinced that this would be good for the incumbent
vendors represented by EHRA, and the list of founding vendors there:
http://www.himssehra.org/ASP/members.asp does seem to match quite
nicely with my description of "big incumbent". Besides recent Open
Source solutions like CONNECT, OHT, MOSS and Mirth, these are some of
the few organizations that have the largest competent in-house
expertise in IHE. If both NHIN Exchange and NHIN Direct both require
IHE, that list of big and incumbent vendors stands to make a lot of
money. Much more so than for any of the other protocol stacks. In this
case EHRA is just acting to support the best financial interests of
its constituents. Which is why I said that EHRA's recommendation is
essentially count against this protocol. It is essentially a tacit
admission from that protocols supporters that they have a considerable
financial bias. Maybe IHE is still the way to go, but at I am now less
likely to trust the arguments made by that group on face value because
of EHRA's recommendation.
>
> You're right that a bridge is needed (you said "bride" but I thought
> that was a humorous Freudian slip since we're talking communication
> here :-).
that is pretty funny. fixed it ;)
> I've also heard the AOL/Compuserve analogy before: it just
> doesn't fit. IHE may not be everyone's favorite choice, but it is
> based on industry standards and an open-consensus process, unlike
> proprietary networks of old.
Ok, I can see that. I have added that it is also like the
Twitter/identi.ca/Google Buzz split. Three basically open networks
that do not communicate.
> Another statement you made was that IHE
> makes "EHR integration" a requirement, whereas the demo yesterday
> clearly showed participation of non-EHRs (e.g., e-mail clients) at the
> edges.
To receive messages. I understood that SMTP/HTTP/whatever could not
send messages without at least having a patient id and that means no
EHR... no sending.
Since participation really requires bi-directional communication, I
think that is a fair statement.
Although I would love to have an updated status on the issue. Can you
send over IHE without a patient id.. with just "health address" plus
"text message"?
> I read plenty of flaming opinions and
> assumptions about the motivations of others, totally unsubstantiated
> by facts; I appreciate (in contrast) your effort to be balanced. But
> there were a few "charged words" and generalizations/inferences about
> "big" etc., that I felt I should comment on.
As you can see above... "big and incumbent" was actually me pulling my
punches... but I will try and make still more balanced.
Thanks for the comments!!
Peter DeVault
(1) NHIN Direct is not an "open source" project. That phrase is not used anywhere on the NHIN Direct home page. (However, "open government" is, but that is a very different thing.) It is, in fact, "a set of standards, services and policies." Source, open or otherwise, doesn't apply to these things.
Doing a search for that phrase "open source" on the whole NHIN Direct website turns up the following comments from Brian Behlendorf (someone who knows his open source): "The NHIN Direct specifications will be usable by proprietary software, and will not compel anyone to release any code... It should be just fine, as I see it, to have other implementations, proprietary or otherwise, involved even during the pilots." The open source requirement is purely for contributions made to the reference implementation, as is appropriate for a reference.
(2) The letter sent from the EHRA to the ONC and members of NHIN Direct (available here http://nhindirect.org/file/view/06042010+EHR+Association+Letter_NHIN+Direct.pdf) presents exactly the kind of meritocratically-minded set of arguments you suggest should help us determine how best to implement NHIN Direct. The fact that the EHRA supports the IHE approach should not sway us into following it. However, to ignore the arguments put forth because the were put forth by the EHRA sounds disingenuous in a discussion containing so frequent a use of the word "open."
Let's all please keep our arguments to the point; we've done a pretty good job of that so far.
Peter
-----Original Message-----
From: nhindirec...@googlegroups.com [mailto:nhindirec...@googlegroups.com] On Behalf Of fred trotter
Sent: Wednesday, June 09, 2010 1:56 PM
To: nhindirect-discuss
Subject: Re: Thoughts on protocol choices
David,
Thanks for the discussion...
> To say that just because a group like EHRA supports something that
> means it must be wrong is backward logic. It should be a meritocracy,
> and there should not "guilt by association."
A little known fact about EHRA is that it is not an "EHR Vendor
>
> As for IHE, I published a list of who supports XDS, and the list is
> public and transparent and updated after each Connectathon.
> http://nhindirect.org/message/view/Concrete+Model+Comparison/24993643
> People can judge for themselves by looking at the list who is big and
> who is not, but I think it's not accurate to make a sweeping
> generalization about "big" and "incumbent."
Obviously there are lots of organizations that are backing IHE. There
are lots of good Open Source projects there now too. Hell I am one of
the people who "supports IHE". But I am backing IHE for NHIN
Exchange/CONNECT, and I am not yet convinced that it makes sense for
NHIN Direct. I am convinced that this would be good for the incumbent
vendors represented by EHRA, and the list of founding vendors there:
http://www.himssehra.org/ASP/members.asp does seem to match quite
nicely with my description of "big incumbent". Besides recent Open
Source solutions like CONNECT, OHT, MOSS and Mirth, these are some of
the few organizations that have the largest competent in-house
expertise in IHE. If both NHIN Exchange and NHIN Direct both require
IHE, that list of big and incumbent vendors stands to make a lot of
money. Much more so than for any of the other protocol stacks. In this
case EHRA is just acting to support the best financial interests of
its constituents. Which is why I said that EHRA's recommendation is
essentially count against this protocol. It is essentially a tacit
admission from that protocols supporters that they have a considerable
financial bias. Maybe IHE is still the way to go, but at I am now less
likely to trust the arguments made by that group on face value because
of EHRA's recommendation.
>
> You're right that a bridge is needed (you said "bride" but I thought
> that was a humorous Freudian slip since we're talking communication
> here :-).
that is pretty funny. fixed it ;)
> I've also heard the AOL/Compuserve analogy before: it just
> doesn't fit. IHE may not be everyone's favorite choice, but it is
> based on industry standards and an open-consensus process, unlike
> proprietary networks of old.
Ok, I can see that. I have added that it is also like the
Twitter/identi.ca/Google Buzz split. Three basically open networks
that do not communicate.
> Another statement you made was that IHE
> makes "EHR integration" a requirement, whereas the demo yesterday
> clearly showed participation of non-EHRs (e.g., e-mail clients) at the
> edges.
To receive messages. I understood that SMTP/HTTP/whatever could not
send messages without at least having a patient id and that means no
EHR... no sending.
Since participation really requires bi-directional communication, I
think that is a fair statement.
Although I would love to have an updated status on the issue. Can you
send over IHE without a patient id.. with just "health address" plus
"text message"?
> I read plenty of flaming opinions and
> assumptions about the motivations of others, totally unsubstantiated
> by facts; I appreciate (in contrast) your effort to be balanced. But
> there were a few "charged words" and generalizations/inferences about
> "big" etc., that I felt I should comment on.
As you can see above... "big and incumbent" was actually me pulling my
punches... but I will try and make still more balanced.
Thanks for the comments!!
-FT
--
Fred Trotter
http://www.fredtrotter.com
--
You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
To post to this group, send email to nhindirec...@googlegroups.com.
To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.
Adrian Gropper
Some of us were thrilled to see the new ONC break the monoculture approach by making CCR a component of Meaningful Use and we truly look forward to NHIN Direct allowing for alternative, Internet-native, approaches to mandated and federally supported HIT standards.
Adrian
Adrian Gropper MD
MedCommons
agro...@medcommons.net
Arien Malec
Coordinator, NHIN Direct
arien...@nhindirect.org
(510) 761-6473
fred trotter
On Wed, Jun 9, 2010 at 11:37 PM, Peter DeVault <Pe...@epic.com> wrote:
> Fred, I have a couple of observations to contribute:
>
> (1) NHIN Direct is not an "open source" project.
You might see the fact that it is Open Source as a side effect, but others of us see it as the only hope for the project and the only reason we are here. Probably just have to agree to disagree on the importance of this. But if you want proof that it is an Open Source project, look here http://code.google.com/p/nhin-d-rest/ not on the front page.
> (2) The letter sent from the EHRA to the ONC and members of NHIN Direct (available here http://nhindirect.org/file/view/06042010+EHR+Association+Letter_NHIN+Direct.pdf) presents exactly the kind of meritocratically-minded set of arguments you suggest should help us determine how best to implement NHIN Direct.
In fact, it -potentially- represents the notion that the network architecture should be closed to people who disagree with a particular worldview.
Its a subtle assumption and missed easily until you explicitly point it out.
The assumption is that it is wise for doctors to invest in same generation of healthcare technology that they largely refused to purchase in the free market. The elephant in the room here is that the members of EHRA failed to provide technology that would be widely adopted without government subsidy. This project, the CONNECT project, the whole HITECH stimulus package is a very expensive concession that doctors, on their own, have not seen the value in what was "on the shelf" as far as EHRs go. We are correcting a market failure here, and an organization representing the companies that participated in that market failure as sellers is now requesting that we choose a software architecture that will strongly favor incumbent technology players. If a doctor came to me and said "should I buy an EHR?" I would say "If you can, wait five years". Depending on how this project goes I might also say "Get an NHIN Direct account in the interim".
The EHRA document goes on to support that basic flawed premise with straw-man arguments.
Specifically this letter says:
"for example, switching to an e‐mail client in the middle of an EHR workflow or reauthenticating to a web form are extra steps that add complexity to exchange"
But one of the successes of the IHE implementation group was to show that you could step/down/up from SMTP messages (and by implication also XMPP or REST). So you could easily bridge messages from NHIN Exchange to NHIN Direct and back using that mechanism. Indeed, the NHIN Direct network would lack lots of meta-data, but the messages would still work and no separate interface would be needed. Those who supported the metadata would get to use it, those that did not... would not. So you are arguing against a straw-man, a deployment model that no one would recommend no matter what protocol is ultimately chosen.
If you look at further "arguments" you can see that in fact, it is just a reworking of the same premise that "EHRA style EHR = good":
"we must realize that ARRA HITECH incentives exist to significantly increase the percentage of providers with EHRs"
No, ARRA HITECH is designed to make doctors into "meaningful users", which may or may not mean implementing EHRA-style EHR systems.
"The fact that most commercial EHR systems and many HIE solutions support protocols in the IHE family today speaks to the scalability of this proposed approach, which can rapidly leverage past and current investments in HIE standards and technology."
Frankly without a nationwide deployment of NHIN Exchange, there is literally no evidence of this. In fact, it would be more honest to say "God in heaven we hope this IHE thing scales". But we know that REST, XMPP and SMTP have vast scaling capabilities. All of them have larger communication networks already running then we will be able to achieve with the NHIN. In fact the scalability of the IHE solution is probably one of the most problematic of the given protocols.
"Building on IHE‐defined protocols also provides a robust framework for sustainability given the fact that IHE's stakeholder participants include medical societies, government agencies, provider organizations, trade associations, and software vendors."
I would rewrite this to say "IHE has a solid development framework, assuming that you have a business model throws off so much capital, that you can support an engineer to work full time on a standards body, for a decade." IHE excludes those without resources. This is a side effect of any standards building that is attempting to build something -huge-. But here you are presuming your argument: If we should be using something -huge- then we need a process like the IHE process to sustain it. Perhaps we need something much much simpler, and allow higher level functionality and capacity to develop on top of it. If we need something simpler, than the processes of IHE are not something to brag about, they are a failure.
Probably the most problematic statement in the whole document is this one:
"An IHE implementation for NHIN Direct puts this project on the most straightforward path to integration with NHIN Exchange"
You are essentially arguing that NHIN Direct should go with a IHE-as-core model rather than the obvious alternative which is bridge-to-IHE. But you do not even mention the alternative model or give any evidence to suggest that the IHE-as-core model is better than the obvious alternative.
When you add up this argument style, you are politicking. To be "open" you have to be willing to discuss the flaws in your own ideas, the limitations of your own approaches. You have to put forward more than mere assertions, you must have either evidence or argument.
> Let's all please keep our arguments to the point; we've done a pretty good job of that so far.
I can see that this post might be taken as argumentative, and that is not my intention at all. I just want to point out that many of us have very different agendas with NHIN Direct than those that are compatible with the EHRA. I have a problem with the fact that they reject Open Source. I know from reading/talking with that both Gropper and Kibbe disagree with the basic EHR model as typically put forward by EHRA. Ironically, I often disagree with their reasons for disagreeing. But I agree that they have the right to disagree. My "Open Source" bias is no less valid than their biases, and most importantly the EHRA biases are no more, or less valid than any of ours. The whole point here is to try to reach the greatest point of common ground. That might be IHE, but it makes me very uncomfortable that you and EHRA are arguing for it in this manner. As long as you continue to try to sway people with this style of arguments, I will continue to point out the utter lack of merit in those arguments and that style.
The irony here is that I think the IHE model, even a IHE centric model has lots of merit. Especially if we can find ways around some of the sticking points.
It appears to me that the current revisions of the IHE-as-core, that you must have at least a patient id, and therefore some kind of EHR, to send messages. That seems to me to be totally unacceptable. It also seems unacceptable that you cannot send messages that are "not about a patient" or about a bunch of patients, as discussed in the call today. But I am not convinced that either of these statements are true. So often in these technical debates, people argue against the "typical" use of a protocol, rather than the breadth of what the protocol is capable of. (XMPP had this happen today too) Can someone authoritatively post to the list the relevant portions of the specs in question? Does IHE messages -have- to be about a patient? Are we certain?
Moreover, the balkanization that would happen if we have direct messaging in NHIN Exchange and a seperate NHIN Direct message is really unacceptable. We cannot have a "facebook status" vs. twitter vs googlebuzz thing happen here. We need both NHIN Direct and NHIN Exchange to be safe decisions for clinicians and patients who want to think in terms of push messaging.
It seems obvious to me that IHE, given that so many people will choose to participate primarily in the NHIN Exchange, is something that NHIN Direct should be inter-operating with. The question is how? I could see IHE as core working, but only if it can meet the use cases: use without an EHR, use to send patient-less messages. But alternatively, maybe we should be thinking in terms of a bridge. Where we "step-up" and "step-down" messages at the connection to the counterpart network, and not at the "edge" of NHIN Direct at all.
Hard to say.
I can understand how you might be somewhat frustrated by my style of exposition. If it helps I find politicking in the context of technical decisions intolerable. Makes me cross-eyed. But just because your arguing style annoys me, does not mean that you are wrong. There are tremendous benefits to built-in NHIN Exchange interoperability and I think some form of IHE message exchange needs to be a formal part of NHIN Direct, even if we ultimately choose another backbone protocol. I think that "working with an IHE bridge" should really be a minimum use-case.
Lastly, I would like to discuss the CCD/CCR controversy.... ;D