Implementation Group Meeting 2010-06-15

Presentation: NHIN IG 06152010.pdf

Notes from the NHIN Direct Implementation Group

Date: June 15, 2010
Time: 3pm-4:30pm
Attendees: Allscripts, Amedisys, American Academy of Family Physicians, Argonne National Laboratory, Axolotl, CareSpark, Cerner, CSC, eClinicalWorks, Epic, Gartner, GE, Greenway Medical Technologies, Harris Corporation, IBM, Inpriva, Kryptiq, Massachusetts eHealth Collaborative, MedAllies, Medical University of SC, South Carolina Research Authority, Medicity, MedNet, MedPlus, Inc./Quest Diagnostics, Microsoft, Mirth Corporation, Misys Open Source Solutions MOSS, MITA, Oracle Health Sciences Global Strategies, Oregon's Strategic Workgroup for the HIT Oversight Council, Redwood MedNet, RelayHealth, Rhode Island Quality Institute, Secure Exchange Solutions, Siemens, Social Security Administration, SureScripts, VA, VisionShare, High Pine Associates

Actions from this 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/22/10

Actions from last week

#	Date	Action	Status	Owner	Due Date
1	6/10/10	Provide any feedback on HITSC review process to Jackie Key or post on the discussion tab of the following wiki page: [1]	Open	IG	6/17/10
2	6/10/10	Communicate to Dixie Baker John Moehrke’s feedback that HITSC review group should be sensitive as to how their recommendation is presented to other groups (such as the HITPC)	Open	Arien	6/17/10
3	6/11/10	Address the objections raised during today’s discussion for each implementation option	Open	Concrete Implementation Teams	6/17/10

Notes:
Arien Malec

• We were unable to achieve consensus during last week’s face-to-face meetings on Thursday and Friday
• Purpose of today’s meeting is to debrief where we are today and discuss ways to proceed forward

Consensus Discussion & Decision Summary

• Most organizations were willing to support all options
• SOAP/IHE approach garnered the most first-preference support and also the most vetoes
  • Most EHR vendors have already enabled some level of support for XDSb. The easiest thing to support is the thing you’ve already done.
  • An important subset of participants believe that while the XDSb specifications are appropriate for healthcare enterprise level exchange, some organizations are interested in seeing solutions from outside of traditional healthcare to support small providers
  • Belief that IHE implementation costs are too high
• Strong overall support for email at the edge
• Tepid, but near universal support for REST
  • Two of the organizations that were co-developers of the REST reference implementation decided to support another protocol as their first preference
• We nearly reached consensus in a couple of directions
• Our distance to consensus is short, but could be steep

HITSC Review Process

• HITSC review group provided a recommendation to:
  • Further development and piloting of the REST implementation, with SMTP email provided by the HISP as an option
• Privacy and Security tiger team is willing to work with Implementation Group to reach the final NHIN Direct solution
• Feedback from HITSC review group included requirements, which should not be viewed as mandates

Issues Identified During Consensus Process

• SOAP/IHE
  • Separation of routing/content metadata
  • Enable transport of content not related to a single patient
  • Substantially drop total implementation costs
  • Address business case for organizations already supporting small practices
• REST
  • Demonstration of cross-conversion to SMTP and XDR
  • Define ability to address additional metadata
  • Demonstration of critical scalability items
  • Risk analysis
  • Automated testing
• SMTP

o Better define error handing and exception processes
o Define ability to address additional metadata
o Presence of viewers for health content
o Address cost of data centers to add new infrastructure not currently supported
o Trusted paths of routing
o Address extension
o Risk analysis
o Automated testing

• • Address risks of users using their current email clients

Proposed Approaches for Path Forward

• Two approaches:
  • As suggested by Wes Rishel, continue to develop 2-3 implementation approaches by forming communities of interest around each approach
  • Seek common ground and unify the group around a single approach
    • Simplify SMTP stack to a level that would address current concerns
    • Define IHE more around metadata than around transport, with an option to use SMTP along with recommended use of XDM
• Open to suggestions from the group on other potential paths forward

Rich Elmore

• Optimistic that all participants said that they would support the group’s final decision
• Concerned about having multiple, competing approaches
• Think that we’ll have more power, critical mass, and national engagement if we choose one unambiguous way to do this
• One key concern with the IHE approach is scale: if you think about the scale of what we’re trying to build for messaging, the only proven technological solution for that environment is SMTP
  • We may run into scale problems if we move forward with REST, IHE
• Three basic needs to address:
  • Provide for national secure email exchange
  • Enable interoperable message exchange with PHRs and EHRs
  • Allow for other kinds of innovations that may not be allowed by IHE
• I had previously endorsed IHE, but understand Sean’s concerns and believe that putting SMTP into the backbone would be a good approach
• Our current proposal is a SMTP backbone, with an IHE protocol at edge and an open architecture for other plug-ins on the edge
• We should define a broader definition of the HISP, with particular attention to IHE step ups/downs and other plug-ins
• By doing our proposed approach, we’d have greater assurance that we’d get the speed of adoption and critical mass needed.
• This approach would also allow us to engage with provider and patient communities where they are today, using email. We’d also be able to engage hospitals/physicians that are using EHRs.

Arien Malec

• Note that I’ve been chastised for talking about “IHE” as an approach, when really this is a SOAP approach. All the teams have endorsed a IHE approach in the form of a XDM zip file.
• We’ve reached a common level of acceptance on a recommendation for content packaging

Vassil Peytchev

• Rich’s proposal seems to be the inverse of the IHE backbone and SMTP edge option. Is this correct?
• Also concerned about the use of the NHIN D-Agent and trust at the HISP-level. All WGs should address these security concerns.
• Arien Malec - Agree, we should ask the teams to conduct a security review of the NHIN D-Agent

Arien Malec

• David McCallie is working on a formal proposal for the approach described by Rich Elmore. This proposal would include SMTP as the backbone, Karen’s Cross handling using XDM content packaging, and a gateway function to enable interoperability with NHIN Exchange. There would several edge options, including email/XDR/REST, as long as the sender can provide a XDM package or something that can be handled in internet message format.

Keith Boone

• We need to find common ground and unify the group around this. If we continue to work separately, we’ll wind up with multiple solutions and may miss the mark on our objectives as a group.
• Agree with the approach have a SMTP backbone supporting XDM content. This would assure a solid pathway into the current NHIN Exchange approach, with way to step up/down into existing NHIN Exchange.

David McCallie

• Agree with Rich’s statement about the way forward. We would have the advantage of scalability, likely using TLS connections to ensure that the channel and content are encrypted. Using RESTful services would make edge integration easy.
• At the IHE gateway, if there’s any metadata present, we could use XDM. We should work with the IHE team to make this step up/down as transparent as possible.
  • Overtime, the market will determine the right amount of metadata to be exchanged.
  • For now, we should leave metadata as unconstrained as possible

Arien Malec

• We’ll want to recommend the use of a metadata-rich container such as XDM

Sean Nolan

• We want a backbone that can scale and meet the market, while supporting the edges that are appropriate for the different use cases
• Microsoft is enthusiastic about this approach

Karen Witting

• I don’t buy into the scale argument. SOAP is based on HTTP, and HTTP can scale very well. I don’t see a reason to choose SMTP over SOAP for reasons of scale.
• The concept of a simple upgrade for email to meet security needs will not be simple. Based on this, I’m hesitant about using email on backbone and uncomfortable with using it on the edge. HITSC also was concerned about email on backbone for security reasons.
• Everyone seems to agree that we need to do conversions, whether for the backbone or edge. The only difference between backbone and edge is what’s required of every HISP.
• We should narrow our focus to discussing either SMTP or SOAP and do some analysis on which would be better for edge vs backbone
• Arien Malec – To clarify, the scale issue is primarily based on the proven ability for a model that’s similar to SMTP to handle asynchronous message delivery. There are off-the-shelf, well-vetted SMTP options available to create the simplest-possible HISP.
• Sean Nolan – Also would add the operational aspects of running the service as part of the scalability concern
• Karen Witting – Still disagree, web servers have been around

Vassil Peytchev

• Is it fair to say that store/forward should be a requirement for the implementation?
• Arien Malec – Let’s table this question until we get through the list

Dan Russler

• According to democratic tradition, we should recognize the majority and embrace the minority
• I feel that we are letting the minority rule the majority
• We can’t support the minority when they have incorrect facts
• Oracle echoes IBM on SOAP scalability – there are 9 million patients using SOAP now. This concern should be taken off the table.
• We should support the ISP model, this is an important minority. The backbone should be SOAP and we’ll accommodate minority by accepting SMTP transactions at HISP
• We should remind ourselves who the patient and physician populations are that will be using this

Arien Malec

• From a process perspective, we agreed that if we couldn’t reach consensus, we would continue to move forward and try to leave the fewest behind
• We didn’t want a process with a majority/minority divide
• Dan Russler – I was suggesting that there is a way to move forward with consensus by embracing majority and minority
• Arien Malec – It would be a shame to put together an approach that would leave two consumer-oriented organizations off the table, we were in danger of this
  • We don’t want to delay this decision endlessly, but we shouldn’t decide to go forward without finding a consensus that brings as many people along as possible

Wes Rishel

• I don’t believe the majority position has expressed willingness to embrace the minority
• Suggest that we work on a proposal that the minority thinks is acceptable and see if there is enough support to move forward
• From a technical scalability perspective, HTTP is a great way to access the web and do large-scale implementations. The question is the ability for a wide variety of small and large organizations to put something in place. Agree with Sean’s point of view, which would support this latter type of scalability.

Arien Malec

• If we’re in a position of picking between two approaches that would leave organizations off the table, I would be inclined to go with the approach that has the most active support and existing implementation
• It would be wrong to look for consensus and leave organizations off the table

Ravi Madden

• Agree with Karen on security concerns for REST and SMTP
• These concerns shouldn’t be taken lightly given the magnitude, the number of end users that are expected to connect to this. This needs to be analyzed further before we prematurely choose an approach.
• Everyone should review the research done previously on this subject.

Mark Gingrich

• Trying to understand the proposal. Haven’t experienced issues with scale using a RESTful solution.

Arien Malec

• Scaling may be a red herring. Concur with Karen that scalability is a function of an implementation, not a specification. We are trying to agree on a specification, not an implementation.
• Could be potentially easier to take off-the-shelf software to scale a solution. Also, a lot is dependent on the NHIN D-agent’s ability filter.
• Many HIEs are not scaling on the transport layer

Mark Gingrich

• Willing to support all approaches
• The SMTP backbone approach seems counterintuitive, SOAP would make more sense

Lin Wan

• Is it possible to do a multi-hop model with SMTP?
• Will SMTP be extensible in the future, not just in the content space but also the transport space?
  • Arien Malec – Yes, you would be able to extend into the transport space
• Has the IHE group demonstrated looking up an address using UDDI?
  • Karen Witting – The IHE demo did not show address look-up using UDDI, but NHIN Exchange does this today
  • Lin Wan – Did the demo use an email address?
  • Karen Witting – We did an address look-up in the demo, but it was using a provider directory that the vendor had in their product
  • Lin Wan – We would need to look carefully at this question, there would be infrastructure/code that would need to be available
  • Vassil Peytchev – This would be true for every implementation, both for source/destination look-up and HISP routing/addressing
  • Arien Malec – REST/SMTP have demonstrated the ability to use DNS to do addressing/routing, but both need to do risk assessment and analysis

David Kibbe

• Not fair to talk about majorities, big vendors get the largest voice
• Agree with perspective presented by Rich Elmore

Arien Malec

• Let’s stop talking about majority vs minority, this won’t help us reach consensus
• The conversations over weekend were productive and moving toward a consensus view
• I would encourage people to not look for differences/disagreements or focus on “why my approach is better” and instead try to talk about how their approach addresses the other sides’ concerns
  • Every team can cite real-world experience about why their approach is best

Doug Arnold

• We should make sure to represent the interests of small physicians

Brian Ahier

• To echo Doug Arnold, small practices are not able to participate in these calls
• Agree with approach to build toward consensus. Think we should go with Wes’ approach to have two communities of interest.

Keith Boone

• Any discussion of scalability should go back to evidence, we need to stop relying on expert opinions because we are a community of experts who can endlessly agree/disagree
• We should head back to trying to find a way forward
• I don’t think that we should divide and concur
• Agree with the idea for a SMTP backbone and a way to step up/down to sophisticated HIEs
  • This would meet needs of SOAP-based infrastructure and smaller providers who can’t tap into this infrastructure

Sean Nolan

• Think that the currently discussed definition of scalability is wrong for what we’re trying to do

Arien Malec

• Many of the questions raised today regarding SMTP are addressed in Sean’s response to issues raised during consensus. We’ll also add another issue based on Vassil’s comment.

Wes Rishel

• Each side has a right to be frustrated, each side is giving way in some respect
• What is the proposal for a non-SMTP backbone? There are different levels of scalability based on the complexity of this proposal

David Tao

• Would like to see a unified approach
• Proposal from Rich is almost the inverse of the original IHE approach proposed last week
• Siemens would support either approach in the interest of consensus, but would prefer aSOAP backbone. However, both Rich’s proposal and the IHE proposal would meet NHIN Direct requirements. Both involve a bridge, avoiding the balkanization problem.

Vassil Peytchev

• In order to address misunderstandings and communication issues between the various teams, each community (SMTP and SOAP) should provide a description of how their proposal works from the point of view from both a source and destination. More explanation is needed.

Arien Malec

• There is confusion about the proposals
• Note that the only organization that has provided a complete end-end specification is REST
• Overall controversy is less about the edge, everyone agrees that the edge should be simple
• The primary area of disagreement is around the simplicity of HISP
• A proposal that describes all of the required pieces to make this work end-end would be valuable

Sean Nolan

• What output would be asked for this? Concerned that we might just be delaying the decision further

Arien Malec

• We need one place that describes in sufficient detail all of the parts that are required to make the approach work
• This may already exist in the capability worksheets

David McCallie

• We could create a spreadsheet that has a list of the steps that would need to be performed for an end-end transaction, with columns for each team

Vassil Peytchev

• The worksheets were designed for an end-end approach, we should have a similar document for the two proposals discussed today
• We should concentrate on the capabilities of source/destination in the different cases

Arien Malec

• David McCallie and Sean should collaborate on describing the SMTP proposal
• The SOAP backbone team should describe how the SOAP backbone proposal works end-end
• We also should continue ongoing discussions to get to consensus
• Aim to reach consensus by Friday