Family Health Guy

In which Sean talks about HealthVault and other cool ideas in Personal Health

Content vs Transport, 2015 Style

Content vs Transport, 2015 Style

  • Comments 1

I’m afraid ONC has goofed with the changes they’ve proposed regarding the use of Direct secure messaging in the just-released 2015 Voluntary Certification Criteria NPRM. I’ve submitted these comments to them directly (ha, get it?), but am also posting here in the hopes of generating more discussion around the issue. I think it’s pretty important.

Comments on Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria (RIN 0991-AB92), Content & Transport revisions.

I am writing to share concerns about proposed Content and Transport / Direct Messaging rule revisions in the 2015 NPRM. I appreciate the opportunity to comment, and would be happy to respond to any requests for clarification or further detail on these issues. As a core member of the founding group that created the Direct Secure Messaging standard, I hope I can offer a useful and relevant perspective.

The 2014 rule contains two measures that rely on Direct messaging --- exchanging care summaries in C/CDA format between providers, and sharing the same from providers to patients. The tests for these measures are relatively simple --- NIST has a Direct system for testing, and the candidate EHR must be able to exchange valid messages with it.

In the new proposed rule, ONC responded to community requests to “separate content from transport.” Because the C/CDA format and Direct might evolve independently, tying them together reduces flexibility. This makes total sense … we’ve had that issue bite us in HIT standards before, back when we tied everything to SOAP and WS* (Microsoft has to take some blame for that one along with everyone else).

The problem is --- the rule changes don’t do that at all. They just change what transport is tied to the content. And worse, this new “transport” is under-specified to such a degree that there is no way to guarantee interoperability with it. It’s frankly a big mess.

To explain, let me back up a bit. When we were first designing Direct, we theorized that it might be useful if an organization could “outsource” message transport to a third party, in exactly the same way that many organizations do for regular email. We called these organizations “HISPs,” and we architected the technology so that the message transport could be easily (but optionally) decoupled from a “client” EHR system that wanted to send and receive messages:

 

We very explicitly chose not to specify the “edge” transport, because we envisioned tons of different EHR/HISP configurations useful in different situations --- and we were right. Systems like Epic were able to accelerate their development by leveraging existing XDR capability; HealthVault uses file drops because that’s convenient for us; others just use SMTP over a trusted channel; Relay/McKesson uses a custom lightweight SOAP approach, Cerner does something I have no idea what it is, and so on. The point is --- it doesn’t matter, because what is important is that we all use the same “backbone” transport of Direct to achieve interoperability.

The 2015 proposals change this approach by explicitly defining a finite set of certified edge transports as detailed in a new work product, the “Implementation Guide for Direct Edge Protocols.” EHRs would be required to use one of these edge transports to send a valid C/CDA to a HISP, which then presumably will send it off using Direct.

Which finally brings us to the three key problems:

  1. The new rule doesn’t separate content from transport at all. It just replaces “Direct” with “XDR, SMTP, IMAP4 or POP3”. They’re all transports. If we really want to separate content (and that’s a fine idea), we need to do it correctly and create tests that validate C/CDAs in full isolation.
     
  2. The edge systems in the proposed IG are dramatically underspecified. Just as one example, the guidance for SMTP as an edge transport says in effect “comply with RFCs 2821 and 2487.” Neither of these RFCs say anything about how the channel should be authenticated, which means there is a good chance that any given EHR and HISP will not be able to work together.
     
  3. The new rule limits flexibility in the very place we need it. As described above, there is great variability in the edge transports that different systems have chosen to use … with good reason, because there is great variability in the EHR systems themselves. And there is a natural market between EHRs and HISPs that eliminates any need for mandates. For example, given Epic’s market presence, every credible HISP will happily implement whatever edge transport they choose.

It is fair to say that, in cases where an EHR has chosen to rely on an external HISP, it is a bit awkward to certify under the 2014 regime. But it clearly has worked --- and because it is a functional test that requires a complete end-to-end test with the NIST system, we have seen an exceptionally high degree of interoperability emerge in the real world. Breaking apart this end-to-end chain by only testing EHRs against (incompletely defined) “edge transports” will surely result in less, not more, success.

In short, the referenced Direct Edge Systems IG should not be part of any rulemaking at this time.

We’ve got a good thing going with Direct. The technology works, it’s being implemented widely, and the trust fabric is growing more complete every day. Please, let’s not mess it up now … we’re so close.

 

Leave a Comment
  • Please add 4 and 3 and type the answer here:
  • Post
  • These certification nut cases are going to mess this up for everyone. It is a fine idea to seperate content but they must be validated in isolation. Direct Edge Systems IG should stay out of it. Sean, your the one that can save us all, we are counting on you. lol

Page 1 of 1 (1 items)