The Purpose of Direct
Let's start with the purpose of the Direct Project which you can find in the project overview:The Direct project specifies a simple, secure, scalable, standards-based way for participants to send authenticated, encrypted health information directly to known, trusted recipients over the Internet.Direct was promoted as being the on-ramp to Health Information Exchange. As an on-ramp, Direct technically has succeeded. It is certainly technically possible to use direct to exchange information between providers, or to patients. In execution, it has pretty much failed to deliver to those expectations. These challenges aren't technical, they are organizational and related to the Healthcare provider. Until we solve those issues, I don't want to rely on Direct (or anything else) until we have resolved the exchange issues between providers.
We need more than an On-Ramp
We need more than a on-ramp for exchange. Direct as it stands is a one-way push. As a push specification, it can only address known, trusted entities. It cannot deal with exchange with unknown entities, and the developing trust framework does not have any way at present to deal with establishing trust in a near real-time way.
Another challenge with the Direct Project is that there's no real way to do dynamic almost-real-time queries, and it is NOT ideal for handling other sorts of queries, even though it is feasible. There is a small group of people who have promoted it for this purpose, but several attempts at creating a consensus body to further develop Direct to support query has not yet succeeded.
Meaningful Innovation
Direct was supposed to resolve a short term problem which, as it turns out is much bigger than the technical issues it was supposed to solve. At present, there are other innovative activities which are more promising than Direct (e.g., FHIR), which require attention. I really want to stop trying to catch the train that's already left the station (e.g., the next stage of Meaningful Use), and spend more time on meaningful innovations in Healthcare IT.
If you had a choice to advance yesterday's compromise solution (and to be sure, Direct was exactly that), or to work on more forward looking forms of Health information exchange, which would you do?
[3rd time's the charm; apparently I can't type today!]
ReplyDeleteI'm advocating for a roadmap that builds out tomorrow's technology while tweaking today's. Specifically with respect to patient data access, I'm advocating for:
1. Let's define the APIs we want, in a forward-looking way. And more than "define" -- we need to build these systems! SMART Platforms is collaborating with the FHIR community to build this architecture today. We're working with partners who want to build the future instead of waiting for it.
* http://smartplatforms.org/2014/08/smart-advice-on-jason-and-pcast/
2. Meanwhile, let's implement small tweaks to a set of infrastructure (Direct) that's widely "deployed" for patient access -- but generally broken. Let's leverage the wide install base by fixing things up in two narrow ways:
* http://smartplatforms.org/2014/08/improving-patient-access-small-steps-and-patch-ups/
* http://smartplatforms.org/2014/09/certification-and-mu-tweaks-for-patient-subscriptions/
Your tweaks are pretty reasonable, and actually do very little about extending Direct beyond its original intent (more like enabling it to meet that intent). That's a lot different from applying Direct to do things like Public Health reporting, Query/Response, and others.
ReplyDeleteKeith:
ReplyDeleteYour arguments as presented are inaccurate.
1. Direct does not require trust beyond the Applicability Statement requirements, which is the only document that has reached consensus concerning trust requirements. The Direct wiki project overview itself is community authored and meant to represent ongoing development as opposed to being fixed and historical. Even MU requirements have been subject to refinements.
2. Direct does not require that parties know each other beyond use of valid identity certificates (NIST Level of Assurance 3). Of course, all HIPAA requirements apply here in terms of exchange, but Direct cannot define which use case actors can communicate with other use case actors.
3. “On-Ramp” is a meaningless term if Direct can be extended to do useful things, such as queries, which is a work in progress; FHIR may be useful as an expression of vocabulary for the queries.
4. Consensus to use Direct for queries has recently been achieved and efforts to realize Direct’s potential will continue.
5. The organizational challenges to current implementations of Direct is a business layer issue, which ONC has never adequately addressed.
6. Direct is not only a one-way push, since bidirectional push exchanges are possible as my company has demonstrated as reference on the Direct Project wiki http://wiki.directproject.org/Pub-Sub+Deployment+Model+with+HISPs.
7. FHIR is a draft standard that has yet to be proven, while Direct is a proven technology with significant untapped potential and has a low bar to entry without only being an on-ramp.
8. Direct was not intended to solve a short-term problem, but the longer term problem of interoperability by being strictly a secure transport mechanism at its layer, which is totally agnostic to content and simple to implement.
We need guidance in which building block to use for which interaction pattern. I see three basic interaction patterns that we use: push, query-response and publish-subscribe.
ReplyDeleteNow I have Direct, Exchange (IHE specs) and FHIR in my toolbox. I can use each of them to support these interaction patterns. Some might be better than others, but I can still do it. If I need to maximize my interoperability (and marketshare) I need to support all combinations.
Thanks ONC for the job security.
Keith - I welcome your response to my previous post so we can further discuss your proposed constraints on DIrect. Thanks - Steve
ReplyDeleteExtending Direct to use cases such as Public Health reporting and Query/Response, etc. provides a simple and economical means of transport, just as it does for MU2 closed-loop referral. Implementing Direct via the kind of architecture Anonymous mentioned--mesh networks of pub/sub nodes that asynchronously push payloads to one another--enables any nodes to connect securely with any other nodes in near-real time with minimal bandwidth consumption, architectural complexity, hardware requirements, and expense. Considering the issues currently plaguing ONC--including interoperability, cost and security--Direct offers a way to solve such problems without interfering with other implementations.
ReplyDeleteSteve,
DeleteI didn't both to respond to your first post because I don't like to waste my time. Since you asked, I'll respond to your points:
1. Technically accurate and I never said otherwise. It's is organizational trust barriers that are the issue, not technical ones.
2. If I must have your address to communicate with you, you must be known. That quote by the way, it from Direct, NOT from me.
3. On-Ramp was the term provided by ONC, not by me.
4. Consensus to use queries HAD not been achieved or widely publicized when I read that note. Of course, if you change the consensus group, you change the consensus. Others have NOT chosen to use Direct for query response. Your mileage may vary.
5. I agreed and made that point.
6. Direct is IN fact a one way push protocol. It could be used for two way conversations, but I have yet to see a published consensus specification for it. Just because you can do something doesn't make it a good idea.
7. Direct is almost as unproven as FHIR, given what I've seen about its use in the wild. My point about FHIR is that is where I want to focus my time and attention.
8. Were you there when ONC staffers said what I wrote, about Direct solving the short term problem of needing an On-ramp? I was. Those aren't my words again.
If you want to exercise your perogative to perform query/response over direct, feel free to do so. I frankly think it is a waste of time. I also think Direct was a waste of time given where we are with it today. Here we are three and four years later, and the technology it was "supposed to replace" is still around and still being used, and still working for folks, and yet I'm seeing daily struggles with Direct.
Do you know how people are using Direct today and integrating it with their products? They are installing an SMTP server with their software. If you want to call that minimal requirements, feel free. I think that leaves a LOT to be desired.