Healthcare Messages Over the Internet: The DirectProject

An announcement regarding the Direct Project...

---

Healthcare Messages Over the Internet: The Direct Project

by Brian Ahier, Rich Elmore and David C. Kibbe

November 29, 2010

The Direct Project announced today the completion of its open-source connectivity-enabling  software and the start of a series of pilots that will be demonstrating directed secure messaging for healthcare stakeholders over the internet.  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.

Also announced:  

• A new name - the Direct Project was previously known as NHIN Direct
• An NHIN University course, The Direct Project - Where We Are Today, to be presented by Arien Malec, November 29 at 1 PM ET, sponsored by the National eHealth Collaborative
• An extensive list of HIT vendors (20+) that have announced plans to leverage the Direct Project for message transport in connection with their solutions and services
• Presentations at the HIT Standards Committee on Tuesday November 30 where three or more vendors will be announcing their support for the Direct Project.
• A thorough documentation library including a Direct Project Overview
• Best practice guidance for directed messaging based on the policy work of the Privacy and Security Tiger team
• A new web site at DirectProject.org
• A new hashtag #directproject for following the Direct Project on twitter.

The Direct Project is the collaborative and voluntary work of a group of healthcare stakeholders representing more than 50 provider, state, HIE and HIT vendor organizations.  Over 200 participants have contributed to the project.  It’s rapid progress, transparency, and community consensus approach have established it as a model of how to drive innovation at a national level.

What is The Direct Project?

Today, communication of health information among providers and patients is most often achieved by sending paper through the mail or via fax. The Direct Project seeks to benefit patients and providers by improving the transport of health information, making it faster, more secure, and less expensive. The Direct Project will facilitate “direct” communication patterns with an eye toward approaching more advanced levels of interoperability than simple paper can provide.

The Direct Project provides for universal boundaryless addressing to other Direct Project participants using a health internet “email-like” address.  

The Direct Project focuses on the technical standards and services necessary to securely transport content from point A to point B and does not specify the actual content exchanged. When The Direct Project is used by providers to transport and share qualifying clinical content, the combination of content and The Direct Project-specified transport standards may satisfy some Stage 1 Meaningful Use requirements. For example, a primary care physician who is referring a patient to a specialist can use The Direct Project to send a clinical summary of that patient to the specialist and to receive a summary of the consultation.

How might the Direct Project be Used?

2009-10 Congress and agencies of the federal government have created regulations that require physicians and hospitals participating in the ARRA/HITECH incentives awarded for meaningful use of EHR technology to:

• send messages and data to each other for referral and care coordination purposes;
• send alerts and reminders for preventive care to their patients;
• send patients clinical summaries of their visit and of their health information
• receive lab results from labs
• send immunization and syndromic surveillance data to public health agencies
• integrate with HIT vendor systems

Each capability can be enabled with point-to-point secure e-mail or in a more integrated manner as HIT vendors and public health agencies enable communication with the Direct Project.

How will the Direct Project affect states and Health Information Exchanges?

States that are receiving federal funding to enable message exchange are being asked by the ONC to facilitate Stage 1 Meaningful Use information exchange.  The Direct Project may serve as a key enabler of directed messaging for all states and Health Information Exchanges.  Even states that have some level of health information exchange capability need to address areas that are currently uncovered by a regional or local Health Information Organization (HIO).

As state plans seek to address a means to fill the gaps in exchange capability coverage, the Direct Project may provide a bridge to enabling the basic exchange requirements for Stage 1 Meaningful Use. The Direct Project does not obviate the need for state planning for HIE, neither does it undercut the business case for HIOs. More robust services can be layered over simple directed messaging that will provide value to exchange participants.

There are already organizations that have announced the establishment of national clinical exchange networks, including integration with the Direct Project. States and HIO’s will need to decide how best to provide Direct Project services to their constituents, whether by partnering with existing exchange networks or incorporating direct messaging into the services they provide.

The Direct Project Implementation

The Direct Project is organizing real-world pilots to demonstrate health information exchange using The Direct Project standards and services.  Six pilots are ramping up including:  

Rhode Island Quality Institute, Redwood MedNet and MedAllies will be sending Continuity of Care Documents to other providers for referrals and transitions of care.  Visionshare will be linking to immunization registries. Carespark (Tennesee) will be linking the VA with private clinics providing health services to veterans.  And Connecticut’s Medical Professional Services, an IPA,  will be linking Middlesex Hospital with primary care providers.

The Reference Implementation

To help the Direct Project implementers, an open source reference implementation of the Direct Project standards and services has been developed under the guidance of the Direct Project. To ensure the broadest possible participation, the reference implementation has been implemented in two flavors:  Java and .Net.  

The HISP

Connectivity among providers is facilitated by Health Information Service Providers (HISP).  HISP describes both a function (the management of security and transport for directed exchange) and an organizational model (an organization that performs HISP functions on behalf of the sending or receiving organization or individual).

Best Practices

The Direct Project is bound by a set of policies that have been recommended to the HIT Policy Committee (HITPC) or are being examined by the HITPC’s Privacy and Security Tiger Team for directed messaging. Within this context, the Direct Project has developed best practice guidance for secure communication of health data among health care participants who already know and trust each other. The Direct Project assumes that the Sender is responsible for several minimum requirements before sending data, including the collection of patient consent. These requirements may or may not be handled in an electronic health record, but they are handled nonetheless, even when sharing information today via paper or fax. For example, a sender may call to ask whether a fax was sent to the correct fax number and was received by the intended provider.

The following best practices provide context for the Direct Project standards and services:

• The Sender has obtained the patient’s consent to send the information to the Receiver.
• The Sender and Receiver ensure that the patient’s privacy preferences are being honored.
• The Sender of a Direct Project transmission has determined that it is clinically and legally appropriate to send the information to the Receiver.
• The Sender has determined that the Receiver’s address is correct.
• The Sender has communicated to the receiver, perhaps out-of-band, the purpose for exchanging the information.
• The Sender and Receiver do not require common or pre-negotiated patient identifiers. Similar to the exchange of fax or paper documents, there is no expectation that a received message will be automatically matched to a patient or automatically filed in an EHR.
• The communication will be performed in a secure, encrypted, and reliable way, as described in the detailed The Direct Project technical specifications.
• When the HISP is a separate entity from the sending or receiving organization, best practice guidance for the HISP has been developed for privacy, security and transparency.

What it isn’t

The Direct Project is not targeted at complex scenarios, such as an unconscious patient who is brought by ambulance to an Emergency Department. In the unconscious patient scenario, a provider in the ED must “search and discover” whether this patient has records available from any accessible clinical source.  This type of broad query is not a simple and direct and therefore requires a more robust set of health information exchange tools and services that The Direct Project does not provide.

The Direct Project in Context of the Nationwide Health Information Network

The Direct Project is an integral component in a broader national strategy to have an interconnected health system through a Nationwide Health Information Network (NHIN). The NHIN is “a set of standards, services and policies that enable secure health information exchange over the Internet. The NHIN will provide a foundation for the exchange of health IT across diverse entities, within communities and across the country, helping to achieve the goals of the HITECH Act.”

The authors:

Brian Ahier is chairman of the State of Oregon’s Health Information Technology Oversight Council Technology Workgroup.  Rich Elmore is Vice President, Strategic Initiatives at Allscripts.  David C. Kibbe is a family physician, senior advisor to American Academy of Family Physicians and co-founder of the Clinical Groupware Collaborative.

How open should a standards project be?

David Tao asks on the Direct Project Blog:  How Open and Broad Should an Interoperability Project, like the Direct Project, Be? John Moerhke provided his response focusing on numbers (which for Direct seemed to be of a good enough size to generate the necessary code, and on process).  I want to look at it from a slightly different angle.

It's a great question, but I want to analyze it a bit further:  How are decisions about who gets to participate made, and under what rules of governance?  One of the very early complaints (and I know because I made some of them), is that the "rules" under which the Direct project operates are not clear, written down or or even developed through any sort of consensus process.

The goal of the Direct project was to support the "little guy" in the small physician practice, without even an EHR system.  If the bar is set to high, little guys won't be able to participate unless there is some other mechanism established to pull them in.

As David points out:

On the other hand, if an arbitrary limit is set (e.g., no more than 20 organizations) then a project might face credibility problems down the road due to lack of openness, and lower probability of people "buying into" and adopting specifications in which they could not participate.

The notion of openness is so important that the Federal government has public OMB circular A-119 which provides guidelines on use of and participation in the development of concensus based standards.

This circular defines a consensus standards thus (see the second link in the sentence above):

... A voluntary consensus standards body is defined by the following attributes:

1. Openness.
2. Balance of interest.
3. Due process.
4. An appeals process.
5. Consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.

ANSI (The American National Standards Institute) publishes ANSI Essential Requirements which includes in its table of contents the following headings:

1.0 ESSENTIAL REQUIREMENTS FOR DUE PROCESS
1.1 Openness
1.2 Lack of dominance
1.3 Balance
1.4 Coordination and harmonization
1.5 Notification of standards development
1.6 Consideration of views and objections
1.7 Consensus vote
1.8 Appeals
1.9 Written procedures
   ...

I highlight that last point, because that is what the Direct project lacks, and before any limits are set on participation, what is needed are those procedures, and they surely ought to be agreed to by a consensus process.  I applaud David for ensuring that there was a forum in the Direct project to have this discussion...

So, Direct, and more broadly, ONC, if you want to play in the standards game, you should do so under the rules that have already been established for Federal agencies and for SDOs.

An Alternative Approach for how to use the NIEM

In Adopting the NIEM for Health Information Exchange Joel Massou talks about replacing the current set of standards that many of us have been working on over the last decade years with new XML content.  While he makes many key points (e.g., concept naming and software development requirements), I disagree with the overall approach.

The key approach that I think is important from the NIEM is not the current set of data models, but rather the approaches used in harmonization.  I'm told that the key here in the NIEM is to engage committed stakeholders and in the processes used to obtain consensus.  Having seen how some of these processes played out in NHIN Direct, I think that NIEM may be on to something, but more work is clearly needed.

If you've read this blog before, you've seen me reference Glen Marshall's excellent article on the Standards Value Chain.  The point is that it takes time (sometimes as longer than five years) to go from the development of a standard to release in a product.  It all depends upon market demand.  ONC has already created a demand for the CCD and CDA standards in the Interim Final Rule.  Changing that would be a disaster at this stage of the game.  Too many have already headed down the path because providers need products using these standards yesterday.

Changing standards in the middle of this process will take even more time.  There should be an evolution in the standards along the lines that Joel suggests, rather than a revolution.  In fact, this is an ideal time in HL7 to address this needed change.  The Structured Documents Workgroup is presently working on the next release of CDA and on Green CDA, the ITS workgroup is reviewing several simpler ITS forms including hData and MicroITS, Clinical Decision Support is searching for models, and everybody is trying to simplify.  An evolutionary path will be sustainable.

My father's imparted wisdom comes to mind again, this time, about trying to change horses in midstream, and the effects that it has on both schedules and quality of work.

Are we lost?

For the last four years, the healthcare standards imperatives in the US have largely been driven by AHIC, ONC, CCHIT and use cases delivered to ANSI/HITSP.  Now that the HITSP and CCHIT contracts have ended, and meaningful use is in the process of being enacted those drivers no longer exist.  This has to some degree caused a shift in what we are working on in healthcare standards.

So what is happening in the meantime?

HL7 is working on an overall model of healthcare in at least five different initiatives:

• hData
• Micro-ITS
• VMR
• A framework based on the EHR Functional Model
• Green CDA

There's progress on some of these, yet not a lot convergence, and quite a good deal of overlap.  I'd say we are still in the "Research" phase of this R&D effort on standardization.  When we get there, I think this will be a pretty disruptive innovation (see my previous post reviewing the Innovator's Dilemma where this term is described).

IHE is focusing on refining HIE oriented profiles in the IT Infrastructure Committee, Patient Care Coordination is focused on meaningful use in perinatal and post-natal care, and Cardiology is working on the Image enabled office.  IHE Radiology is examining Web services.  There are few breakthrough activities going on here; most of what I see is sustaining innovation.

NHIN Direct is the one US government initiative that is getting some attention, although it is behind by about a month after delays in obtaining consensus (now nearly achieved). 

The HITSP Harmonization process is due to be replaced by an NIEM oriented process, but while submissions were due back in March, nothing has been announced.

The industry is still waiting for various details of the "Meaningful Use" regulations to be completed, some of which are expected "REAL SOON NOW".

The abscense of a strong "requirements" driver in the US is clearly having an impact on standards initiatives here.  Collaboration among the various standards bodies is reduced due to the lack of deadline driven projects.  Most of us are waiting for the other shoe to drop, mostly on several regulatory fronts, including standards, meaningful use incentives, and long term certification, but also on standards and harmonization contracts due to be announced by ONC.

Does that mean the standards community is lost?  I don't think so.  But I do welcome the opportunity to "catch my breath".  The last four years have been very intense.  While I would do it all over again in a heartbeat, I'm glad I'm not at that level of intensity right now.  I expect that to change any day now.

I appreciate the struggle that HL7 is going through right now.  They've latched onto an old problem (models of healthcare information) and are seeing it in a very new light (simplicity in use and access) and at a higher level of abstraction that the RIM.  Given that many workgroups are currently struggling with the same issues, I expect that there will be some divergence for a few more months, followed by a convergence and reinvigoration of HL7 Version 3 activities focused on making it more readily used.  My hope is that a reemergence of a strong driver in US government activities will not distract HL7 from engaging in this work.

IHE PCC has started some work in a new paradigm in Patient Care Coordination that addresses workflows crossing various healthcare settings.  That space will probably produce a profile a year for the next three or four years.  This too is sustaining work, and I believe will continue regardless of what happens here in the US.

White smoke?

We've gotten a lot closer in another week.  It appears that the Convergence Proposal put written up by Rich Elmore and David McCallie has been able to get general agreement from just about all parties.  It includes many of the capabilities that I talked about yesterday in "A way forward", and we also looked at some really good pictures developed by Janet Campbell.

There are some clarifications needed before we make a general call for consensus on the project, and a team has been put together to make those clarifications (I'm on it along with Rich, David and a few other people who have also be "working hard" this week).

My last comments on this are that we need to address requirements of Source HISP and Destination HISP, not just "requirements of the HISP", and that we also need to determine what the existence of an NHIN Direct address implies.  Some e-mail addresses in the real world are send-only and don't recieve, and others are recieve only and never send.  Is that allowed in NHIN Direct?  It seems like it should be.

In any case, I think we are very close, and we'll be able to announce what the NHIN Direct protocol is next week.

Working Hard on NHIN Direct

A lot of my focus this week is on NHIN Direct and trying to work towards consensus.  That means that I haven't been focused on other topics ... and so some would have it that I'm hardly working.  Is NHIN Direct undermining meaningful use?  Only meaningful use of incentive payment kind, not real world meaningful use, so I continue to participate.

Wes Rishel reports on his opinions of where Vendors are in NHIN Direct: Response to Comment on Vendor Positions.  What I find amusing about this is that I know of several cases where "we" are still deciding where "we" are, and if you talk to two different individuals at the same employer, you will get two somewhat different answers on what that "we" thinks.  Some of this is readily apparent if you look at the e-mail threads of the workgroups.  I also find myself clearly in all three groups that Wes identifies, and can put others clearly in at least two, depending on the definition of "big" and "substantial", and other similarly imprecise terms.  Wes, please do me a favor identify companies or don't, but don't take half measures that can be confusing.

It's fair to say that vendors (I won't speak for any specific segment) haven't yet coallesced around a single solution yet for NHIN Direct; that's still a work in progress, though we may get more progress later today.

On Andy's specific comments:
...HIE Vendors should be fairly neutral...
I'm not sure about that.   Whatever gets done, if there's two protocols established, there will be two to support, and given where consensus has been driving us, I expect there will be two protocols.  Yes, whatever the second protocol is, it will be pretty easy to develop (and likely support), but that won't make it "free".  I'd like to have it be supported based what is already in the installed base, because that will reduce implementation costs.

...pushback might be coming from the EMR vendors...Their core competency is clinical EMR development, not interoperability...
Wow!  My autoclassifier marks that last statement with [citation needed], especially given that the source is someone who works for a vendor of "interoperability solutions".  Look at my responses above with respect to "HIE Vendors".  The same principle applies.

...NHIN Direct sets too low a bar...
NHIN Direct sets a very low bar conciously.  As time marched onwards, that bar became MUCH lower than the bar set for meaningful use.  This occured even though the original project description states that it: "... will expand the standards and service descriptions available to the NHIN to address the key Stage 1 requirements for meaningful use, and provide an easy "on-ramp" for a wide set of providers and organizations ...". 

Yes, I'm a little bit concerned that the bar is too low, but that is more of a market opportunity than a problem for me.  It's easy enough to raise that bar to provide better services.  Going from CDA/CCD or CCR to XDM is very simple, and I've written stylesheets in a day or two that support that several times over.

In the interest of full disclosure, I work for GE Healthcare, which is a vendor of Healthcare products that includes EMR and HIE solutions.  Also, and as always, the opinions expressed on this blog are my own and not necessarily those of my employer.

A way forward for NHIN Direct

There are two communities of interest that NHIN addresses, those already engaged in the NHIN Exchange who want to be able to capitalize on their existing technology investment, and those providers who do not have access to technology that is capable of integrating with the current NHIN Exchange specifications and policies.  NHIN Direct is focused on meeting the needs of that latter group, but we need to remember that group will need to communicate with the group already invested in NHIN Exchange.

This is, I believe, the real impasse in the current NHIN Direct work.

What we need to remember is that there is one National Health Information Network, and that the purpose of NHIN Direct is to enable providers who cannot communicate via NHIN Exchange to participate in NHIN.

The current NHIN Exchange also includes several other components that may also be problematic for these providers, because the current set of policies (including the DURSA) may also be too complex.  I won't bother to address issues of policy other than to point out that there is an HIT Policy committee that will be advising on those.

Let us just take it as a given that NHIN needs to support both communities:

We have two "backbone" proposals (SOAP with IHE XDR or SMTP) that are more or less desirable between one community or the other.  Movement of one community or another towards the "backbone" that meets the needs of the other has implementation costs that neither community really wants to be responsible for.

Whether we call SMTP the backbone or SOAP+XDR the backbone really doesn't matter (at least to me).  We will want to bridge between these two communities of interest.

Let us name three protocols:
Protocol A uses IHE XDR with SOAP
Protocol B uses SMTP and includes an XDM content package in the content.
Protocol C just uses SMTP and any sort of attachment desired.

So, we have providers with the following sets of cababilities:

1. XDR and/or XDS.b capabities through NHIN Exchange.  These are users of protocol A.
2. SMTP + some level of services to produce an XDM package. These are users of protocol B.
3. SMTP.  These are users of protocol C.

We need to enable exchanges between all three sets of providers as much as possible.  In order to do that, each NHIN Exchange participant will need to have an NHIN Direct address that they can use to communicate with parties that are not in the NHIN Exchange.  That same address can also be used to when routing communications between NHIN Exchange participants.

If a party in group 1 wants to communicate to another party in group 1, here is the overall process:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HISP forwards that communication to the Destination HISP
3. The Destination HISP delivers the pushed content to the Destination System using XDR

If a party in group 1 wants to communicate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communicates to the Source HISP via XDR.
2. The Source HITSP S/MIME encrypts the content
3. The Source HISP converts the XDR metadata and content to an XDM Zip file an attaches it to the communication.
4. The Source HISP locates the destination HISP via the destination address in the XDR informationRecipient metadata.
5. The Source HISP sends it via SMTP+TLS to the destination HISP.
6. The Destination HISP stores the encrypted content until requested by the Destination System.
7. The Destination System requests the content.
8. The Destination HISP descrypts the S/MIME encrypted content and sends it to Destination System (via POP or IMAP).

If a party in group 2 or 3 wants to communciate to a party in group 2 or 3, here is the overall process that could take place:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP stores the encrypted content until requested by the Destinatio Edge System
6. The Destination System requests the content.
7. The Destination HISP descrypts the S/MIME encrypted content
8. The Destination HISP sends it to Destination System (via POP or IMAP).

Now, a distinction appears in the protocol when we want to go from B to A or C to A.  Let's look at B to A first:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. The Destination HISP sends the XDM content via XDR through a simple transform that requires no manipulation of PHI, and only deals with protocol bridging.

Now let's look at C to A:

1. The Source System communciates the MIME package to the source HISP via SMTP+TLS
2. The Source HISP S/MIME encrypts the content.
3. The Source HISP locates the Destination HISP via the destination address in the MIME package.
4. The Source HISP sents the S/MIME package to the Destination HISP via SMTP+TLS
5. The Destination HISP decrypts the S/MIME encrypted content.
6. * The Destination HISP fails to locate an XDM package and sends a message back to the source HISP indicating that the content could not be transmitted.

Step 6 is a problem, but not an insurmountable one, and we've already covered almost all cases.  There are a couple of ways that a software component could eliminate the rejection in step 6, depending on the content and communication intent:

1. The message is simply a "text e-mail" with no attachments directed to the destination address.  For example: "I'm sending John Doe to you to have an EKG because he has a history of hypertension.  Could you send the results back to me when you are done.  Thank you.  Dr. Smith"
2. The message includes an attachment in a non-healthcare format (e.g., PDF) or a proprietary format (e.g., RTF).
3. The message also includes an attachment in a healthcare standard format (e.g., CCD or CCR) and that attachment is from the medical record of the patient who the communication is about. (Add "P.S., I've added John's CCD to this e-mail" to the previous case).
4. The message includes an attachment in a healthcare standard format, and that attachment is not from the medical record of the patient who the communication is about.  "I'm sending you the information about the delivery of Jane Doe's baby John as she tells me that you will be John's pediatrician.  Attached please find her delivery summary.  Thank you.  Dr. Smith."
5. The message includes multiple attachments for different patients.  "Here are my records for the paitents I immunized today.", and/or "Here is Jane's delivery summary and Baby Doe's discharge summary".
6. The message includes an attachment that is not specific to any single patient.  "Here is my quality report."

Cases 1, 2, 3 and 4 can be made to fit an XDR model by generating a unique random identifier to identify the patient and including minimal metadata in the XDR communication.  What will be lost is any way to have the patient be matched in the NHIN Exchange side.  As we've seen in the media, ensuring that patients are correctly identified during information exchange is important for patient safety.  Users on the NHIN Exchange side will need to deal with cases where patient information comes in where they have to ensure that the patient is correctly identified.  We've also seen examples where content in case 3 can be bridged using a "better" set of metadata, but it is difficult to distinguish those in case 3 from those in case 4.  That could be addressed by including an additional header in the communication that indicated that the Attachments in the communication are related to the patient that the communication is about.

That leaves the last two cases.  Batching and quality reporting is NOT a requirement for phase 1 of NHIN direct, although they could be requirements of future phases.  The two documents from different medical records pertinent to one patient is arguably a rare case that we can better work the details out for later.

Frankly, I could spend another page proposing solutions to these two cases, and knowing that I could do that is enough to stop here.

I believe there is a way forward.  I believe that way forward will need to include some sort of bridging technology, and I'm very much in favor of recommending XDM content in whatever is selected to support that bridge.  Whether the backbone of NHIN Direct is SMTP or XDR, what we need to realize is that the backbone of NHIN needs to support both.

All of the examples I gave assumed that the Source and Destination HISP's were trusted with the responsibility to encrypt/decrypt the S/MIME package. This is to address certificate deployment issues.

In the examples I gave above, I showed that it was the Destination HISP that was responsible for bridging the content.  Arguably, that bridging step could also be done by the Source HISP, and I see no reason to prevent or discourage that.  Bridging is in fact an additional service that should be offered to enable the existing NHIN Exchange infrastructure to support NHIN Direct.  The examples I just described could actually treat the "bridging component" as the Source or Destination System, which would be a purer way to describe it.  From my perspective, I just see that additional component as fitting best with a software application that performs the HISP role.

P.S.  Actually, group 1 to group 1 is already addressed by current NHIN protocols using a query model and an XDR push model, this exchange group really doesn't need to be addressed by NHIN Direct.

Black smoke on NHIN Direct again

The black smoke continues to billow over NHIN Direct.  On today's Implementation Workgroup call, two basic proposals were made:

1. Continue to develop 2-3 implementation approaches by forming communities of interest around each one (as suggested by Wes Rishel)
• Communities will likely form around SMTP and IHE/SOAP
2. Seek common ground and Unify the Group with a single approach
• SOAP with an e-mail bridge model
• REST with SMTP

There was a lot of discussion, with some of it divisive and some of it trying to work towards consensus.

I believe in general that the group is moving towards trying to seek common ground, and that sentiment was strongly supported by many EHR vendors. 

One of the problems on today's call was that these one line descriptions of the proposals did not present enough information about what was included in them.  We did not come to a decision today, but Vassil Peychev proposed that the remaining proposals be written up and a call be held on Friday to review again. David McCallie and others are working on write-ups now. Given that suggestion occured near then end of the NHIN Direct call, Ariensuggested that be the go forward plan.

Let me briefly summarize how I think these proposals work out:

1. The "go your own road" proposal around communities of interest seemed to be a non-starter.  Two people really supported it, but I heard strong support (including my own) on trying to come to consensus, even though it may be hard.
2. There seem to be two "grand unification theories" going around:
• Use the IHE XDR protocol as the backbone and provide a bridge to the SMTP model.
• Use SMTP as a backbone, with REST as an interface layer, and IHE XDM as recommended content.  This would enable step up/down to/from current NHIN and IHE protocols (XDR and XDS). [I strongly support this theory].

Note that I'd be happy with XDR as the backbone, as the IHE model already demonstrated that capability, and I'm much more comfortable with the security of that model.  That really speaks though to my own comfort level with TLS and SOAP, and clearly, doesn't address the complexity issues that others have raised, nor will it, I believe, be able to move forward as a consensus position, given the fact that two parties are very strongly against that option.  Given that the XDR as a backbone position doesn't seem to be in a position to generate a consensus viewpoint, I very strongly support the next choice.

There was still a great deal of discussion / dissent over the lack of representation from the smaller providers who this is being built for.  The next time this process comes around, there ought to be some sort of provision to provide for them to be directly represented (EHR vendors do have these providers as customers, but representation by proxy is not seen as valid representation; at least in some of this group).

There are also a few who have expressed concerns that large vendors are still dominating the process.  However, I would also note that it seemed to be those same vendors strongly expressing desire to reach consensus, rather than divide up around preferred approaches.  

I also heard some concerns raised that a very small but strong minority opinion was blocking a majority viewpoint, and also that the majority was trying to work with them. 

This was another hot-button topic, and I think that the words minority and/or majority, and large/small vendors are keywords that should be used very carefully in any NHIN Direct call that wants to make progress (I'm just sayin').

There were a number of comments about scalabity of solution A vs. solution B.  In a community of experts however, an expert opinion carries little weight when two or more the experts disagree.  There was one attempt to shift grounds from "technical scalability" to "social scalability" of the two alternatives.  It was an interesting discussion, but I didn't quite get it. 

All in all, it was a pretty intense and wide ranging (perhaps too wide ranging at some points), discussion.

We are all very frustrated, and that comes from a number of places.  The ability of a small group to hold up a larger group, the struggle by under-represented but important stakeholders to have their viewpoints heard, the desire by some (including me) to move things forward.  The newness of this process, our lack of experience with it, and our inability to reach some of our timelines contributes to all of this frustration.

Even with all the frustration, we've gone from four possible outsomes to somewhere around two in a matter of a week, and that is indeed progress.  I have to give Arien Malec a lot of credit (worry not, I'll give him grief like I did a few weeks ago when it is deserved).

Black Smoke over Redmond

Last week develpopers met face-to-face in Redmond to declare a victor among the four protocols proposed for NHIN Direct:

• XMPP
• SMTP
• REST
• IHE+Adapter

If you get the "black smoke" reference, you already understand that no choice was made, and discussion is still occuring.  You may have also read commentators on the Web:

Arien Malec
Wes Rishel
Sean Nolan
John Halamka

I was not able to attend the meeting, but what I'm hearing in general are that:

1. There was a "general consensus" led by EMR vendors for the IHE solution on the backbone.
2. A couple of naysayers against the IHE solution wouldn't come to consensus at all.
3. SMTP seems to be strongly supported for the edge.

To say that I look forward to continued discussion would be disingenuous.  I'd love to be moving on to the next stage, BUT, discussion still needs to occur, so I'll be patient and let it work itself out.  I am thankful that Arien chose the path of trying to obtain agreement, rather than hitting arbitrary deadlines.  As Wes has said in this past, if this project succeeds in twice the time allocated, it will still be a big win.

Governance, SDOs, PEOs and NHIN Direct

Next week I head to Vancouver and then to Milwaukee. In Milwaukee I'll be teaching a generalized course on Interoperability standards to Masters students in software engineering, along with one of my collegues. As part of that course, I teach how to work with standards organizations, and the need for consensus based standards in industry.

As I review the course materials today, I'm looking at some potential disconnects between what I teach, and where I participate. Where I spend most of my time now is in IHE, HL7 and NHIN Direct, and last year, you could replace NHIN Direct with ANSI/HITSP. 

Not too long ago, I spent about an hour getting my ear bent about the governance, processes and status of some of the organizations that I particpate with. IHE International was incorporated in 2009 and its Principles of Governance can be found here.  Anyone who wants to participate in IHE can do so without charge, and after becoming a member, can vote on and participate in any activities.  ANSI/HITSP, while no longer under Federal Contract still maintains its web site.  Documentation about HITSP processes can be found on that site.  When it was active, anyone who wanted to could join HITSP and can vote on and participate in any activities.  HL7 is an accredited ANSI Standards Development organization, and publishes their bylaws and Governance and Operations Manual on the web.  Membership is by fee, but anyone who wants to participate can become a member and can vote on and participate in any activities.  Non-members can also participate in committee discussions on standards and in the HL7 Mailing lists.  HL7 standards can also be voted on by non-members for a modest administrative fee.

HL7 is a Standards Development Organization. IHE and HITSP are (or were in the case of HITSP) Profiling and Enforcement Organizations (PEOs -- an acronym I believe to have been invented by Wes Rishel).  But NHIN Direct is the oddest duck of the lot. 

NHIN Direct is an "Open Government" project.  There's some detail about the NHIN Direct project on their FAQ page.  I have not been able to find detailed documentation about governence or process on the NHIN Direct pages.  Some of it is there, but other parts are missing. 

For example, there are three ways to participate:
1.  By being a member of the core group (which I happen to be).
2.  By joining the wiki and e-mail lists and participating there (which I also do).
3.  By passively participating using the resources provided by NHIN Direct.

Someone from a large research organization that does quite a bit of government work asked me last week how you get into the first group (his organization wasn't able to, but had tried).  I didn't and still don't have an answer.  I know it's by invitation, don't know what the qualifying criteria are, and I have yet to find anything other than what is stated on the FAQ.

Recently, NHIN Direct announced a new co-chair to one of the workgroups.  I wasn't aware that A) there was a vacancy, or B) what the process would be to "run" for that vacancy.  Apparently the process for the selection of leadership NHIN Direct is not documented either.  I didn't see any call for a vote either on the new leadership.  BTW:  I'm not against this particular leader, I think he's a pretty good leader, even though we disagree on several issues of substance.

Back to the class that I will be teaching:  I describe six key features of concensus standards bodies.  These features are derived from the HITSP Tier 2 process (word document), US Federal Law, and a circular published by the Office of Management and Budget describing policies on Federal use and development of voluntary consensus standards and on conformity assessment activities.  Here are my six features, accompanied by an analysis of how NHIN Direct stacks up:

• Open -- Membership should be open to all affected parties.  In NHIN Direct, there are two classes of membership, contributors and decision makers.  Decision making isn't open to all affected parties.
• Balanced  -- Members should come from providers, suppliers and consumers of affected products.  I see some balance in the membership of NHIN Direct, but no documentation of it.
• Process Oriented  -- The organization should have a defined process.  A very weak link here, as there is little documentation of any process in NHIN Direct.
• Appeals -- Decisions should be able to be reviewed and appealed.  I don't see any documentation, nor would I know what those processes would be in NHIN Direct.
• Consensus Based -- Decision making should be based on a consensus of the organization members.  This is one of NHIN Direct's strong points.  It's very clear that everyone has a chance to be heard, and I've actually learned a number of ways to improve consensus building in other organizations where I participate from the NHIN Direct work.
• Maintenance -- Specifications produced need to provide for ongoing maintenance.  Because there's very little documentation about NHIN Direct, and because it is a "Project" of ONC rather than an organization, it's not clear what the ongoing maintenance process will be.

I very much support the activities that NHIN Direct is working on, because I think that they will enable smaller healthcare providers to exchange clinical data between themselves and other providers.  However, NHIN Direct has quite a bit of work to do before I would even consider putting them into the category of a consensus based standards body.

Which leads me to my final questions:  What should be done with the NHIN Direct specifications when they are complete and implemented?  Should they be run through a Standards Development Organization ballot or voting process?  Should NHIN Direct try to become an SDO or PEO (Profiling and Enforcement Organization)?  What do you think?