The Direct Project

From Working Code To Running Pilots: Direct Project Face to Face in San Francisco, 10/27-10/28

We are getting close to a "1.0" release of both a C# and Java implementation of the Direct Project specifications.  These RIs are designed to be incorporated into existing clinical systems, integrated by SaaS healthcare companies, or even used as a stand-alone application.  It's time to start training the technology partners in the different pilot projects (what we call our Implementation Geographies) to get familiar with the code, find gaps that need to be filled, and lay out the steps to launch.  There are also lots and lots of rough edges to smooth out to make the code really usable.  To help do all that, we will be meeting publicly in San Francisco on October 27 and 28 for a "code-a-thon / install-a-thon", and you're invited.

We are making quick progress and have a number of solid contributors, but could use more, especially if this grows like we hope it will.  If you have C# or Java skills, if you want to get deep into what will be a reference tech standard for health data exchange, and if you can dedicate both October 27 and 28 to the effort, please come.  The healthcare technology industry is hiring, and will need developers familiar with the standards, terminology, and technology used in this project.  Healthcare IT can have a steep learning curve, so we will spend the morning of the 27th getting you up to speed on the project and the development environment.

If you can attend, please contact nhindirect@nhindirect.org, as available space is limited.

More information can be found at:

http://nhindirect.org/Direct+Project+October+Face-to-Face+Meeting

You have questions, we have....

1. Yes, I know this blog has been neglected. Trust me, it's because there's way too much stuff going on in the real world. We have 6 workgroups that are producing stuff at phenomenal rate. I need to slow down a bit and summarize for the everyone else...

2. On that note, I know that people who aren't directly involved with the project have tons of questions, and don't know how to get them answered. So, the project has created a way to get your questions answered:

Simply go to the Direct Project FAQ submission page and ask your question. Oh, you have to register to use the blog first, which is highly painless.

The Documentation and Testing Workgroup will take your questions, and create answers. Some questions, and, even better, answers, are already created for your reading pleasure.

CONNECT-Direct direct connect

We had a great day yesterday at the CONNECT Code-A-Thon, walking a bunch of new interested participants through Direct, up to an including the architecture, fundamental classes, and how to get the Java implementation up and running.

We were able to get my laptop running as a HISP, live, no magic. Pretty fun to see a message go in one side plaintext, and out the other side signed and encrypted.

Today, we will be working on the other side of the CONNECT Direct Direct connect; in addition to cross pollinating Direct with the CONNECT folks, we will be working on integrated Direct with a direct connect into CONNECT. (I never get tired of saying that).

There are a number of Federal centers, agencies and departments that would like to use Direct specifications to connect, using CONNECT, directly, for purposes ranging from continuity of care to pushed administrative transactions. The key to this is making sure that an implementation of Direct is directly connected to CONNECT, so that CONNECT can direct connect directed connections.

Progress on the reference implementation front

We've seen considerable momentum after our face to face meeting, along all sorts of fronts.

I want to concentrate today on what I consider to be the key domino we have to knock over to generate a chain of success.

When we first started this endeavor, one of the initial goals was to create a high quality specifications and documentation that allows developers to get involved. We also wanted to create a reference implementation of the specification that software developers could build off of in their code.

I've come to realize that for basic interoperability, the value of a high quality, production ready, open-source implementation is critical. For example, when developers want to exchange data using HTTP, unless they are utter geeks (who like to rebuild stuff for fun), or researchers (for example, who want to build highly parallelized versions), they use the built-in libraries implementing that protocol in their language library.

There will always be reasons to create your own implementation from the base specifications, but for most developers, the path of least resistance should be to check out the commercially friendly open source code, drop it into the source code tree, and start programming against the easy-to-use APIs.

So we've assembled a highly effective team of incredibly talented developers to do just that. That team is still kicking, poking, and prodding the code into shape, but they've made a tremendous amount of progress in a short time, and I wanted to share an interesting graph with you.

Everyone knows that lines of code are a pretty terrible measure of progress, but in this case, they are:

1. One of the better leading indicator metrics we have and
2. Based on high quality, well structured code

This graph shows progress against both the C# and Java reference implementations (we found the software development organizations to be pretty evenly split between C#/.Net and Java), so shows the progress of the teams overall:

The code counts only count written code, omitting comments, whitespace, etc. The comments counts generally are Javadoc/C# XML comments that generate API documents.

In addition to the API documents, the teams are creating installation guides and other reference documentation. We are aiming for the end of this month to be code complete for all the major components.

All an all, a fantastic effort, and I want to thank and praise the team that are working so hard on this:

• Java Reference Implementation
• C# Reference Implementation

Great face to face meeting

Long time, no blog.

Since my last post, we've been hard at work, writing code, planning the future components we will write, writing documentation, and planning to take this out to the real world. We've also been trying to do a much better job of communication what this is all about.

In our face to face meeting yesterday, we started things off with a bang, with parallel code-a-thon, document-a-thon, and plan-a-thons.

On the coding side, we have had some truly heroic work from Umesh Madan and Greg Meyer, and we have lately gotten a robust set of additional volunteers to chip in. We are writing both a Java and C# implementation (because the health IT world is pretty evenly split between those two language stacks), and yesterday we were able to get the teams together to plan out the various components we are writing, and orient everyone to what is already out there.

You can see the energy the team created in the source code changes over the past couple of days.

The implementation planning teams identified some cross team dependencies, particularly on the reference implementation (we need to do a better job getting visible milestones and plans in place so that organizations can schedule when we are bringing this out to the real world), and on documentation and communication (we need to have great materials to bring to the providers and other stakeholders).

The documentation team got to near final on the all important overview document, and established the process to bring the rest of the documents to completion, and the communication group worked out the key priorities for messaging and communication.

We had a great session on policy with Deven McGraw of the Center for Democracy and Trust; Joy Pritts, Chief Privacy Officer at the ONC; and David McCallie of the HIT Standards Committee, who are all on the HIT Policy Committee's Privacy and Security Tiger Team. Deven provided an excellent summary of the Tiger Team recommendation letter that will be presented to the HITPC tomorrow. We all greatly appreciate the work of the Tiger Team, and were pleased to see clear recognition of the specific set of policy issues relevant to directed exchange.

We also had a very informative session on Direct and State HIOs and Regional HIOs that work with the states, with Gary Christensen of RIQI (the only threefer in the country, as a state designated entity for HIE, a REC, and a Beacon community), Will Ross of Redwood Mednet, and Tim Andrews of High Pine Associates, and the leadership of the ONC state HIE team. The main theme of the session is that many organizations are participating in Direct to improve the ability to get information out of EHRs and related systems, and to simplify the approach to assist providers in achieving Stage 1 Meaningful Use, and the associated quality, access and cost goals. A number of the participants commented that directed exchange meets a different set of business needs and has a different set of policy implications than does assembly of a longitudinal health record for clinical quality, and that both are important aspects of a state HIE strategy.

All of the participants left the meeting with a good deal of energy and enthusiasm (indeed, a number decamped to the Holiday Inn Capitol to continue coding in the restaurant there). I would like to thank everyone for their participation, and am greatly looking forward for the next few months, as we make this real!

Huston, we have consensus....

The consensus proposal is now at version 1.1.2, and has reached consensus. Please see my previous summary for more details.

To move this consensus proposal forward, we have launched two new workgroups:

1. The Documentation and Testing Workgroup will create the specification and reference documentation and
2. The Reference Implementation Workgroup will create the actual working code.

In addition, we are moving forward the Implementation Geographies and Security and Trust Workgroups. The other workgroups are going to take a much deserved break while momentum switches to bringing the consensus proposal to life.

Consensus Proposal updated to 1.1

There was a bit of wording in the Consensus Proposal that tripped at least a few people up.

The wording in question stated:

Source HISPs MUST be capable of accepting incoming messages with unencrypted payloads from Sources, and securing and transmitting them using the Security Agent model documented in the appendix below, in accordance with the Security and Trust Consensus Proposal. Source HISPs MUST be capable of receiving Source encrypted transactions and delivering them without further transformation (assuming the Source manages content packaging, keys, signing and encryption).

The wording was taken to indicate that data could be sent unencrypted to the HISP. The Security section (later in the document) makes it clear that all channels MUST be TLS encrypted. The reference in this section is to the actual content payload. (This is the difference between sending plaintext over an encrypted channel, and sending encrypted content over an encrypted channel -- the bits are encrypted over the wire in either case).

I updated the section to specify that the channel must be encrypted (duplicating content from the Security section for greater clarity).

While I was reviewing the section, I realized that I needed to change a MUST to a MAY. It should be possible for a HISP to perform in a mode where it requires the Source to do signing and encrypted. If it performs in that mode, it must reject message bodies that are unencrypted.

Here's the updated language:

Source HISPs MAY be capable of accepting (over TLS encrypted channels) incoming messages with unencrypted payloads from Sources, and securing and transmitting them using the Security Agent model documented in the appendix below, in accordance with the Security and Trust Consensus Proposal. Source HISPs which are not capable of performing content payload signing and encrypting MUST reject unencrypted payloads. Source HISPs MUST be capable of receiving Source encrypted transactions and delivering them without further transformation (assuming the Source manages content packaging, keys, signing and encryption).

I don't think this will change any votes, but wanted to surface the change for reviewers.

Consensus Proposal

At long last, we have a consensus proposal available for full community review and endorsement.

During the concrete implementation rounds, we learned a great deal from concrete development. Among the key lessons:

1. The penetration of XD* SOAP profiles in EHR and HIE technology is significant. Nearly all of the vendors in that space preferred some variant of those profiles, and the team doing a proof of concept with XDR was able to demonstrate impressive workflows on top of existing technology.
2. The SMTP team were able to demonstrate use of existing commodity software (Postfix and Exchange) with an S/MIME-based security agent to enable reliable transport and workflow integration with EHR and PHR systems
3. Plain old email at the edge (with support by strong security and privacy systems at the HISP) had strong support as a way of extending continuity of care transactions to a wide range of providers who do not currently have EHR systems
4. The native email packaging system can carry both unstructured payloads (like ordinary email) and highly structured payloads, and the use of XDM zipped files provides a highly effective bridge between SOAP and SMTP-based transports.

Based on those lessons, we created a consensus proposal for review and endorsement. The main features of the consensus proposal are:

• Support for SMTP with strong privacy and security enabled through TLS and the S/MIME-based security agent as a universal minimum backbone
• Endorsement and recommendation of XDM as the preferred content packaging for SMTP transport
• Support for the NHIN Exchange through endorsement of XDR as the native backbone for NHIN Exchange.

In addition, we intend to enable add-on support for a revised XD*-based SOAP interface that addresses the key criteria from the HIT Policy Committee Privacy and Security Tiger Team to enable addressing and delivery without requiring access to the content metadata package. We encourage the creation of HISPs that speak both XD*/SOAP and SMTP to take advantage of the existing momentum behind XD* SOAP-based interfaces.

Please comment on the consensus proposal.

Presume good intentions

We are working hard to achieve consensus for the NHIN Direct project. As part of that consensus process, we've seen both a good deal of really mature leadership to find common ground, and some assumptions of bad intentions.

For instance, I've heard, in the last 24 hours:

1. This is about large vendors dominating the process to their benefit
2. This is about a vocal minority using process and influence to veto the will of the vast majority
3. This is about a secret strategy by ONC to force everyone into traditional EHRs
4. This is about a secret strategy by large horizontal technology companies to dominate health information exchange by leveraging monopoly positions.

My advice: take a deep breath, presume good intentions unless definitively proven otherwise, and keep talking.

In that vein, I'd like to strongly endose Keith Boone's blog post, which both sets up the key issues in the march towards consensus, and is a very nice example of the value of presuming good intentions.

To code.

Since inception we have been on a very aggressive schedule, often overlapping stages of specification and development in a manner not unlike that suggested by the "Agile Manifesto".  The attempt to decide on one backbone and one edge protocol before we started really coding on the reference implementation was an attempt at optimizing development effort at the expense of Agility.  But making that choice was not strictly necessary. Being efficient with time and resources is important, because there is a lot of work to do beyond writing protocol proofs-of-concept. 

While the formal deliverables of the project are specifications and a reference implementation of those specs to enable adoption, usually one needs to see specs in action to have confidence in their suitability to purpose.  With all due respect to TimBL, few people who saw the WWW.app browser in 1991 (before it supported images and most text formatting) and the CERN httpd could envision a world where people would use its underlying protocols to do online banking or healthcare.  What it took was the brashness of XMosaic and the economy of NCSA httpd for many people to see a generative platform, the beginnings of something big rather than just another experiment in hypertext.

From the beginning, we've talked about the NHIN Direct reference implementation as needing to do more than simply prove that the specifications can be compiled into code.  The practical requirements of moving quickly into pilot mode and the chances that we would be specifying something relatively new meant that few off-the-shelf solutions would necessarily be suitable.  Translating the passion and technical talent of the participants here into common code seemed to work well for the proofs of concept by the Concrete Implementation teams.  Can that be repeated with the reference implementation?

As the abstract model has congealed, it's become apparent that it's the software supporting the HISP that really matters.  Supporting all kinds of client-side code is important too - from people's common mail clients and web browsers to an EHR module  - but the need for standardization and excellence is greatest at the HISP.  It's also the place where the question of "does this scale, up and down, to meet the needs of the kinds of participants we want to enable?" is most directly answerable. To some of us, running an HISP should be no more difficult than running one's own mail server or web server, with a similar range of options for doing so, from free commodity servers that do the basics very well to commercially licensed solutions that can do a lot more.  Most healthcare providers don't run their own mail or web servers; but enabling those who do, and the ISPs/VARs and IT teams that support those docs, would help demonstrate the suitability to purpose of the NHIN Direct efforts.

We've started a page to think about what this solution needs to look like, which we're calling "HISP in a Box". This is just a first take.  There might be a good rationale for saying that some of the requirements that focus on simplicity of installation and administration are not important for the pilot phase.  This page should get us thinking about what tools to pull together, whether and how to support different operating systems and languages, and so on.  It also hopefully demonstrates how those who disagree on which backbone or edge protocol to support in the pilots might still work together on the common code that matters as much to the success of this project as the protocol code does.  Feedback desired through the usual channels - ideally, as comments to that wiki page.

When the Apache httpd development team faced the prospect in 1998 of going multithreaded in its 2.0 version, there was much much debate about the right way to do that.  This logjam cost us well over a year before Dean Gaudet, Manoj Kasichainula, Ryan Bloom, and others got to work on a pluggable API for process/thread management called MPM.  That seemed pretty ambitious at the time - little is as core to a server application as how it manages threads - but it turned out to be the right move, because it broke the development logjam and allowed advocates of different approaches to "compete" in a very collaborative manner.

We could elect to take a similar path - translating the passion and energy of the participants here into code for the project in a way that is, as John Moehrke said, "less about competition and more about cooperation." It allows us to continue to make progress towards pilots without needing to make a firm decision about a single backbone protocol. It might even show us the merits of more than one such backbone, so long as we can still achieve simple interoperability between every HISP and thus every participant.

Brian Behlendorf