Implementation Group Meeting 2010-06-23
Notes from the NHIN Direct Implementation Group
Date: June 23, 2010
Time: 2pm - 3:30pm
Attendees: Axolotl, CareSpark, Center for Democracy & Technology, Cerner, Clinical Groupware Collaborative, CSC, eClinicalWorks, Emdeon, Epic, Gartner, GE, Greenway Medical Technologies, Harris Corporation, High Pine Associates, HLN Consulting, IBM, Inpriva, Kryptiq, MedAllies, Medical University of SC, South Carolina Research Authority, Medicity, MedNet, MedPlus/Quest Diagnostics, Microsoft, Mirth Corporation, Misys Open Source Solutions (MOSS) , ONC, Oregon Health Information Technology Oversight Council, Redwood MedNet, RelayHealth, Rhode Island Quality Institute, Siemens, SureScripts, Techsant Technologies, VA, VisionShare
Actions from this week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 4 |
6/23/10 |
Workgroup to finalize consensus proposal |
Open |
Concrete Implementation Proposal Team |
6/25/10 |
| 5 |
6/23/10 |
Continue ongoing discussions and address questions to drive toward consensus |
Open |
IG |
6/25/10 |
Actions from last week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 1 |
6/15/10 |
Write a detailed description of how each proposal (SOAP-backbone and SMTP backbone) will work from an end-end perspective |
Open |
Concrete Implementation Teams |
6/17/10 |
| 2 |
6/15/10 |
Continue ongoing discussions to drive toward consensus |
Open |
IG |
6/17/10 |
| 3 |
6/15/10 |
Perform security review of the NHIN Direct Agent |
Open |
Concrete Implementation Teams |
6/17/10 |
Agenda
- Review latest NHIN Direct Concrete Implementation Proposal
Notes
Arien Malec
- We will discuss the consensus proposal during this call.
- Acknowledge that we are 2 days past our intended deadline
- Karen expressed very early on that we were on a crazy timeline, and she was right
- That being said, I do believe we’re getting close to a consensus proposal at least from a working group. I’d like to discuss what that consensus proposal is during this call.
- I’ll give a verbal description:
- We have a draft final proposal going through edits. There’s a team composed of representatives from the Concrete Implementation WG. They’ve taken something from each of the proposals and blended them .
- SMTP backbone carrying S/MIME signed and encrypted messages.
- Integrated XDR interface/gateway for out-of-the-box integration with existing XDR implementations.
- Simple REST interface at edge.
- Client interface provided by exposure of standard POP/IMAP email services.
- SMTP as minimum backbone protocol.
- If better mechanism for communication exists (ex. XDR à XDR), an alternative protocol may be used as long as it supports SMTP.
- For NHIN Exchange nodes, recommend use of NHIN Exchange native document submission (XDR)
- Edge Connectivity: Allows for variability at the edge. Allows for:
- Proprietary Edge: Supports providers with enterprise EHRs, Software as a Service EHRs, or other systems that combine EHR and directed exchange capabilities.
- SOAP: Supports providers who use full-featured EHRs or EHR Modules using IHE/SOAP web services
- REST: Supports providers with EHRs or EHR modules who have not implemented a SOAP stack who wish to take advantage of direct messaging. Can be used to create novel integration points, such as web-based portals, for secure message-handling.
- We propose to create a reference implementation of a simple web-based portal, as part of the pilot deliverables
- Email: Supports providers without EHRs or EHR modules who still wish to participate in information exchange.
- Security: Requires the use of S/MIME encrypted and signed content packages to preserve PHI confidentiality and security
- Allows for message senders to ensure that only authorized recipients can view the PHI
- Allows for message receivers to verify that only authorized senders sent the message.
- Combined with S/MIME encrypted and signed Message Disposition Notification, allows for end-to-end non-repudiation of message delivery and receipt.
- Requires TLS encrypted channels and authentication of all edge systems.
- This is the key outline for the unified proposal.
- The status is that we are close to being finalized within the group, but need a few more eyes. Need to get consensus amongst working group, so expect an email shortly as well as a blog post asking for your endorsement/non-endorsement.
- Now I’d like to open it up to questions.
Wes Rishel
- How much are we nailing down the edge protocol in the sense that we’re talking about end to end non repudiation of delivery? Is every edge required to support that or just specific ones?
Arien Malec
- The current language says that HISPs may support specific edge protocols. There is not a requirement for a HISP to support any particular protocol. It does require HISPs to support status notification. Both the REST and SMTP backbones need to provide status. This is a good question to bring back to group
Wes Rishel
- Are you allowed proprietary edge protocols? As long as it gets data through Internet without exposing information to the world?
Arien Malec
- And meets the functional requirements. Good question.
- Anyone from the consensus proposal team have anything to add? Anyone on the phone whose not able to ask through the Q&A?
Brian Behlendorf
· I think it does make sense to have one document. This proposal does take out the best pieces and puts them into a box. I would prefer, if we have the fundamentals down, that we go one step further.
· There’s a set of language in proposal that’s essentially a core spec – the MUST have SMTP on backbone, and this is how to enable XDR/SOAP as an option.
· The second document would be a pilot technology plan – what we’d like to commit to as a committee for technology specs. Here we can talk about implementating the core specs and adding defined set of edge interfaces that we can make part of what we’re building. This would help implementation geographies project.
· Then there’s a third part –extensions that this community can come up with through the core spec such as the REST interface on edge. It may make sense to talk about what it looks like.
· I think it’s about nailing out process for add-ons and if a subset of community wants to work on it, how they can be most effective.
· I think this really does present the best, but wondering if there’s a way to structure it to be understandable beyond the implementation group. I think this will get a lot of interest.
Arien Malec
· I would agree with that. What we have now is not a specification, it’s an outline for a specification. We will need to create a specification doc in short order. I think the outline you’re proposing with a clear process for add-on proposals makes a lot of sense. I think we should have critical paths for the MUST have features and allow process for strong add-ons. Other questions?
John Moehrke
· Being on vacation last week , what is the set of immutable requirements or guiding principles for further development?
Arien Malec
· I think the intent of the group was to clearly express the MUSTs and SHOULDs. The intent is to clearly document all of the MUSTs and treat those as requirements.
John Moehrke
· More specifically, if health providers are using their own networks, they’re directly communicating. Both have EHRs in the cloud. Is it really necessary to add the additional overhead of S/ MIME?
· As you look through these things it’s important to always look at how this is scoped out. As a guiding principle, S/MIME is a useful tool that we should look to first to satisfy identified risk. But as a mandate, there’s no possible way to allow those two parties to communicate without additional overhead of S/MIME. It’s unnecessary and burdensome.
Arien Malec
· I agree. That was the intent of clarifying that for HISPs that know they speak an additional protocol, they may and we recommend that they use that protocol instead of S/MIME.
· S/MIME is intended as lowest common denominator.
· If we both speak XDR, then we should speak XDR, and there’s no reason for speaking SMTP with an S/MIME container.
· In fact, I think there’s acknowledgement from many of the folks who have been the strongest advocates for STMP as backbone that it’s perfectly feasible that use of SMTP declines as more organizations join NHIN Exchange. That’s a good and desirable thing.
John Moehrke
· I think your previous answer is different. These are really guiding principles, not requirements then.
Arien Malec
· The MUST state is that you MUST support SMTP, but not always use SMTP. You can think of it as MUST or SHOULD as you desire.
John Moehrke
· I like the spirit of what you’re talking about it, but it could be misunderstood.
Wes Rishel
· I want to make sure that I understand this now. Any HISP that claims to do NHIN Direct will be able to communicate with every other HISP at least by SMTP, and they may have specific parallel protocols, correct?
Arien Malec
· That’s correct.
Mike Berry
· Follow up question – Is it possible to send an NHIN Direct message to a recipient who has an S/MIME capable email client but is connected through an ordinary SMTP gateway?
Arien Malec
· Not sure if this will meet security and trust requirements. This is a policy issue more than technical issue.
· Theoretically, if I can take an encrypted message and decrypt locally, there’s no technical reason that I shouldn’t be able to take a commercial SMTP server and use it for that purpose. There are policy considerations that make that unadvisable.
Mike Berry
- I assume that it has to do with HISP conversations with additional encryption using TLS.
Arien Malec
- The other is the policy consideration about an organization or HISP having access to an encrypted EHR.
Sean Nolan
- I think John asked if you’re using SMTP over simple TLS between two parties, would this prevent that. That would be seen as any other backbone. As long as those parties are comfortable with that, that’s fine.
John Moehrke
- My question was more high level on where we use SHOULD. Are these guiding principles or requirements? The example I pulled out is the one you’re talking about. Right now we require S/MIME so if it’s an immutable requirement, that means they can’t use simple SMTP prime. They must use S/MIME and TLS.
Arien Malec
- What we’ll do is make sure to address this, and John could publish suggestions.
- I think we agree on intent and we’re just getting the language to clarify the intent.
Wes Rishel
- Another question, do we still have the concept that the domain name is specifically issued in support of NHIN Direct?
Arien Malec
- I think that’s less a mandate than a practical consideration. I think practically if my domain name is Sunnyside practice and I want regular email and I want to get secure direct exchange, I think I need a dedicated sub-point.
Wes Rishel
- It relates to individual who has an S/MIME client in general email. Suppose he wants to reply to the message.
David Tao
- Basically, it’s been looking promising. It seems there’s a general verbal agreement.
- I think there were a lot of objections coming out in the Google groups. Not sure if this was coming from within this group. It was concerning and I wanted perspective.
- What’s the estimated time of when the implementation group would have the whole thing ready for a vote?
Arien Malec
· The latter question is as early as today. It just depends on some work that the team needs to get through.
· For the former question, I want to be fair and open and say that it’s some external people and some organizations that have some discomfort around SMTP as backbone.
· Two tech objections primarily relate around:
o 1) developer productivity and familiarity with S/MIME versus SOAP or REST
o 2) ease of integrating the S/MIME approach into workflows.
o There’s been a proposal to look at message boxing as a way of integrating.
· Those two concerns are out there and they are legitimate concerns. I would encourage people to get those addressed.
· We’re certainly not going to railroad or steamroll anybody for those objections. At the same time, we’re in a stage where we’ve had a number of people working really hard for a long time. There’s a desire to go forward as long as it’s workable. I want to honor the people who have those concerns. I also want to recognize that there’s a timeframe that we’re going to have to work around.
David Tao
- We knew that everybody was going to think that the most productive protocol was the one they already knew. We’re never going to win that battle for everyone. Hopefully that won’t be enough to break.
Keith Boone
- One of the questions that was raised was concerns of HITSC committee around SMTP. I had made the suggestion that we ask the security and trust workgroup to meet again and do a risk analysis to address those concerns.
Arien Malec
- I completely agree. We’re going to put together our consensus and we’re going to have to work with Tiger Team and the Standards committee and make sure we’re abiding by the policy requirements. I think that action is a key action. I would like to make sure we have consensus first.
Karen Witting
- My concern about SMTP is that I need to see a clear risk analysis. I’m not confident that SMTP can be adequately protected. When I saw the suggestion that security and trust group is going to review, I was glad, but would like to have this happen before our own draft. On Friday, I know that several people have been working on adequately addressing these on the proposal.
Arien Malec
- Fair enough. Let’s make sure that we get that worked on or at least a first assessment done. We’re going to work with the Privacy and Security Tiger Team and the Standards committee in any case, so that is part of the critical path regardless.
Wes Rishel
- I just want to mention that the scheduling of the official security and trust workgroup must be done in a way that there’s sufficient announcement so that the public can attend. We may want to work with Dixie to see if there’s a group that could work in advance and then report back to overall workgroup.
Arien Malec
- We’re talking about two different things – one is the security and trust WG meeting tomorrow and once we do the preliminary analysis, the other is the Privacy and Security Tiger Team review.
- Any other questions?
- Look forward to the finalization of the consensus process. If you do have concerns with the consensus process, please verbalize them early so they can be addressed.
- Please expect to see an endorsement process come through soon. I want to thank everyone for holding through this complex process.