The NHIN Direct team met face to face Thursday and Friday, with a goal of getting to a consensus decision.
We didn't make it, but we did make significant progress.
Here are some highlights from the meeting:
- We asked each implementation group organization which specifications they would be prepared to support. With a few exceptions, most organizations were prepared to support any of the specifications.
- The SOAP/IHE approach had the most "first choice" support, and had near universal support among the EHR vendors (the notable exception is Cerner, which is a strong supporter of the SMTP option). That level of support included the EHR vendors whose primary market base is smaller providers (eClinicalWorks, Greenway, MedPlus, RelayHealth). It also had the most "won't support" sentiment (with three organizations with that sentiment).
- There was strong support overall for email at the edge.
- REST is an approach which could get everyone on board, but had a lower level of enthusiasm overall. Also, two of the organizations that developed the REST reference implementation decided to support another option as their first choice (one for SMTP with REST as a strong second, one for SOAP with REST as a strong second).
The predominant theme was "the simplest approach is the one you already support," and many organizations have already implemented the XDS.b specification, so the level of new code for the SOAP/IHE approach is lower overall.
To meet the concerns of the HITSC and HITPC reviews, the SOAP/IHE approach will have to address the issue of mingled message addressing metadata with content metadata, and to meet the simplicity and documentation goals for the NHIN Direct project and the HITSC Implementation Workgroup findings, will have to improve the level of documentation.
The likely outcome of that work would be a revised XDR specification (we called it an XDD specification during the meeting) that separates addressing metadata from content metadata, and allows the content body to be encrypted without affecting the ability to get the payload to the destination.
Assuming success of that work, we are going to have to choose between bringing everyone on board, at the cost of new development, or re-using code for a significant set of the implementation group, but leaving some key organizations behind. Not an easy choice.