Implementation Group Meeting 2010-06-29

From Direct Project
Jump to navigation Jump to search
Presentation:
[File:http://www.wikispaces.com/i/mime/32/application/pdf.png NHIN IG 06292010.pdf]

Notes from the NHIN Direct Implementation Group


Date: June 29, 2010
Time: 3pm - 4:30pm
Attendees: Allscripts, Atlas Development, Axolotl, CareSpark, Cerner, eClinicalWorks, Emdeon, Epic, GE, Google, Greenway Medical Technologies, Harris Corporation, High Pine Associates, HLN Consulting, Inpriva, Kaiser, Kryptiq, MedAllies, Medicity, MedPATH Networks, MedPlus/Quest Diagnostics, Microsoft, Misys Open Source Solutions (MOSS), MITA, NIH NCI, ONC, Oregon HIE Planning Team, RelayHealth, Rhode Island Quality Institute, Siemens, SureScripts, VA, Vangent, VisionShare

Actions for this week

#
 Date
 Action
 Status
 Owner
 Due Date
6
 6/29/10
 Review consensus proposal and cast vote on wiki
 Open
 IG
 6/30/10
7
 6/29/10
 Put together statement of intent for new workgroups
 Open
 Arien
 6/29/10
8
 6/29/10
 Put together documentation/marketing materials on NHIN Direct
 Open
 Arien
 7/9/10

Actions from last 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

Agenda

  • Review Consensus Proposal
  • Next Steps

Notes
Arien Malec

  • We’re more than a couple weeks off our deadline, but I do expect to make a decision this week and go forward with our deliverables for July.
  • Just as a reminder here are the deliverables for July:
    • Reference Implementations: Provide a high quality open source reference implementation of the recommended specification
    • Reference Implementation Guides: Provide reference implementation guides for edge systems and routing systems (including sample code, testing and conformance documentation, legal and policy documentation, etc...)
    • Conformance Testing Scripts and Services: Provide conformance UATs and an automated conformance service for each concrete implementation
    • Key Implementation Geographies: The Implementation Geographies WG will finalize a set of key geographies for early real-world implementation
    • Interaction Model/Service Orchestration Model: The Abstract Model WG and the Concrete Implementation WG will provide an Interaction Model and Service Orchestration Model
  • There are also deliverables around standards and interoperability framework. We need to get through consensus round before getting to these.
  • Big news this week, as people saw from email, mailing list, and blog, is that we finally have a consensus proposal. It’s been through many rounds of editing from number of concrete implementation team members.
  • There have been a number of updates since we sent out the email. None have changed the intent, just clarifications.
  • Here are some high level remarks about the consensus proposal:
    • The Consensus Proposal can be found at: http://nhindirect.org/Consensus+Proposal
    • The Consensus Proposal is an outline for set of transport specifications. These transport specifications will have two parts:
      • 1) A set of specifications based on SMTP providing a common denominator solution encompassing all providers, and intended as a stepping stone to NHIN Exchange
      • 2) A set of specifications based on XDR allowing participants in NHIN Exchange to fulfill the user stories.
    • Details on MUST, SHOULD, RECOMMEND, etc. usage is defined and referenced. Assumptions about the user are also noted.
    • Proposal adheres to NHIN Direct Design Principles (http://nhindirect.org/Design+Principles) .
  • Right now, it’s not a specification.
  • About NHIN Exchange:
    • The rulemaking process involves some federal partners and contracting partners as well such as VLER, SSA, etc.
    • State HIEs, through their grants, are federal contractors and are also eligible for NHIN Exchange.
      • There’s a process leading up to rulemaking that’s currently underway being advised by HITSP and HITSC and we expect that access will be sent to wider set of participants.
      • So it’s not as limited as people may think, although may be in short term.
    • This is one of key reasons we’re pointing to NHIN Exchange
  • We do expect in this proposal for a long term or medium long term for an NHIN Exchange model.
    • Support for SMTP backbone is important in the short term to get exchange up as quickly as possible.
  • Let’s get going in the short term with common denominator, but provide long term support for NHIN Exchange and evolution towards NHIN Exchange.
  • In terms of security considerations, Sean Nolan has been leading a risk assessment process based on the SMTP backbone. We’ve come up with a couple ways of mitigating risks.
    • Key one being recommendation to leave content encrypted in data stores.
  • Proposal adheres to Security & Trust Consensus Proposal (http://nhindirect.org/Security+and+Trust+Consensus+Proposal)
  • As the details are further developed, security layers will be applied using a Risk Assessment methodology in the context of the assumptions and intended use.
  • Use of standards-based mechanisms such as X.509, TLS, S/MIME, AES, SHA, XML-Digital-Signatures, etc. will be considered to protect against the threats identified in the Risk Assessment.
  • An initial risk assessment threat model is under development and will be completed prior to specification finalization: http://nhindirect.org/Threat+Model+-+SMTP+with+Full+Service+HISPs
  • In terms of details about the protocol, HISPs MUST support SMTP common end-to-end transport protocol.
    • Owner of Health Internet Domain MUST maintain DNS Mail Exchange (MX) and Certificate (CERT) Resource Records (RRs).
    • Source HISPs MUST:
      • Accept incoming messages with unencrypted payloads from Sources, and secure and transmit using Security Agent model.
        • There has been a key update around this statement. It should now read that HISPs must accept unencrypted payload over an encrypted channel.
      • Receive Source encrypted transactions, and deliver without transformation
      • Destination HISPs MUST:
      • Reject attempted delivery of content not packaged according to security and trust model
      • Verify provenance & trust of transaction using Security Agent model; Reject transactions which don’t verify or deliver to a Destination with verification of provenance
      • Ensure Message Disposition Notification sent to inform Source of transaction receipt or error
  • In terms of Edge connectivity – we’re documenting end to end connectivity based on email model.
    • Source and Destination Connectivity
    • Systems MAY combine HISP and Source/Destination capability.
    • HISPs MAY support end-to-end connectivity based on the e-mail connectivity model.
    • E-mail connectivity MUST:
    • Support SMTP client connectivity over a TLS-encrypted channel.
    • Authenticate client connections and reject unencrypted and/or unauthenticated connections.
    • Support POP3 or IMAP4 client connectivity over a TLS-encrypted channel.
    • Destinations MAY reject content that does not meet Destination expectations.
  • Content Packaging:
    • Content Packaging:
    • MUST support the Content Container Specification.
    • Use of XDM zipped files by Source and Destination is RECOMMENDED.
    • Add-on Connectivity:
    • Additional specifications will be added to the minimal end-to-end connectivity model.
    • HISPs MUST support the minimal end-to-end model and are encouraged to move towards support of the NHIN Exchange model.
    • Review Consensus Proposal for additional details for HISP-HISP and Source and Destination Connectivity.
  • Call for Consensus – we’re looking for a yes or no vote. If you do have a no vote, please specify what changes you would like to see in order to endorse the proposal.

Q&A
Keith Boone

  • You mentioned in the early part of the call that we’re two weeks behind schedule, but I think we’re a month or six weeks behind schedule. This failure to reach consensus has stopped work to develop specifications which needs to get done before we reach that second draft stage.
  • We probably have another month to develop that second round of drafts.
  • We need to reevaluate to see where we’re at and ideally be posting an updated schedule and project plan so we’re not trying to operate off of outdated schedule.
  • I’m willing to work on helping to develop detailed technical specifications.

Arien Malec

  • We are 2.5 weeks behind our consensus point. I acknowledge that it’ll take time to complete final details.
  • I’m hoping we can do some work on reference implementation, documentation, and testing in parallel with specification development.
  • It may be better to plan for success and acknowledge that we’re off schedule.
  • We will take that feedback and look at the schedule once again, especially at the end of July date. We may push that date out a bit.

Lee Jones

  • I appreciated the discussion on wiki about point on NHIN. I saw that there was some language put in that there was a distinction about XDR. I
  • worry about statement about why we’re doing this – one of them is the NHIN Exchange piece. I wanted to see if there was a way to reword second bullet so it doesn’t sound like one has to be an NHIN Exchange participant to do an NHIN Direct XDR exchange.

Arien Malec

  • Preamble is to repeat that we will support XDR HISPs outside of NHIN Exchange.

David Tao

  • I feel like there’s a step beyond approval of project group and selling of it to standards committee and policy committee and ONC overall. This fits in with documentation needed.
  • You said something like “has to conform to content container specification.”
  • For those who are not living things every day, they may not understand this.
  • We should account for some sort of simple self-contained presentation document that doesn’t have links to other documents.
  • Since the whole idea is to be simple, we should make the output simple for the non-initiated audience.

Arien Malec

  • Completely agree. Three needs:
    • An English language marketing overview for what this is and what it does that somebody can quickly read and absorb.
    • An all-in-one specification that doesn’t require much in the way of looking outside for specification. Some of that is a little unavoidable, but more explanation will be helpful.
    • The need for reference implementation documentation. An intermediate that will help to understand how to implement that isn’t intended to be normative.
  • I have a presentation tomorrow where I’ve taken Janet’s diagrams. I think we need to iterate those kinds of documents.
  • Appreciate the feedback.

Vassil Peytchev

  • Would like a clarification on NHIN Exchange table, on last two rows.

Arien Malec

  • We want to see XDR backbone that isn’t limited by NHIN Exchange. One is the long running rule making process that will expand access to NHIN Exchange. The other is faster which is to do pure XDR. The bridging will be around DURSA and trust framework rather than technology.

John Moehrke

  • I think there’s still too much conflation of an implementation of solution with specification of what the solution is.
  • The point Vassil was making was that the solution should be speaking about XDR.
  • Conflating the security agent as an implementation of a HISP that can offload some process from the source or destination is a great implementation, but the specification needs to be in pure terms of interoperability requirements. So that yes, you can use the agent, or you could have implemented it yourself or contract with cloud provider whose implemented it. It’s getting better and better. I think there’s still conflation.

Arien Malec

  • I agree. I want to point out that we’re not at a specification at this point. This is a specification for a specification.

John Moehrke

  • I understand that.
  • The more troubling thing is that it seems we have lost the concept of Karen’s cross. The diagram shows that it’s good for NHIN Exchange participants to use NHIN Exchange, but regardless of the fact that they have robust exchange mechanism, they must also host SMTP exchange point. I thought we were making progress on cooperative process so that we have bridging endpoint.

Arien Malec

  • It’s certainly not an intentional change of direction. There are two reasons this reads the way it does.
    • One is the personal belief that the best way for what the comprehensive HIE workgroup ended up calling a full service HIO is the best way for that organization to receive an SMTP transaction and process locally for transformation into XDR.
    • From perspective of VA, it’s a business decision for them to decide if they want to get it transformed first or process it locally. I didn’t say you must do a transformation.
  • I do point out in the document that transformation to and from XDR and SMTP is something we’d like to see in reference implementation.

John Moehrke

  • VA may be a bad example, but an organization like CareSpark would like a single endpoint than forcing hundreds of members to have an SMTP endpoint.

Arien Malec

  • This is written from NHIN Exchange perspective where it’s at a gateway level. The gateway should probably deal with SMTP. But what happens is left unspecified behind gateway.

Tony Malia

  • I’m on VA and VLER. The comments have been good.
  • There’s some coupling we need to look at, and that’s between directories. If we have XDR endpoint in service registry in Exchange and in XDR we have to put the target end user, we have to make sure that the end user is actually a right member of that community. We have directory coupling between these two.

Arien Malec

  • The current UDDI service discovery allows you to discover where the other exchange is, and we need to specify in the XDR specification where the address is. In this document , we have not tied how you discover those addresses into specification itself. It’s actually a precondition that you establish who you want to send and what their address is.

Tony Mallia

  • It’s just an area we have to think about. In NHIN Direct, it assumes a lot of authorizations have already been made. Unfortunately, someone has to do those authorizations. And we already have those done in NHIN Exchange. So this is very much part of enforcement by law regardless whether NHIN Direct supports that or not. It’s a big challenge to think out where common services are and how the mixture is going to work.

Arien Malec

  • We put all those details in simplifying assumptions.

John Moehrke

  • Many of these points are in the simplifying assumptions that we use to simplify the transport.

Arien Malec

  • We will specify interior and exterior diameter, etc. How you put stuff through the pipes is their problem.

Tony Mallia

  • I think we’re getting to point of concrete vision.

Arien Malec

  • Please read through consensus proposal and I’d be happy to address comments you may have.
  • Please get endorsement by end of day Wednesday, June 30th.
  • If you can’t get them in by then, please let us know and we will put in place a reasonable extension. If you don’t do either of those, we treat this as a null endorsement.
  • We will go back and look at schedule and see if we need to push July date to end of July or beginning of August. But I’m very pleased we were able to take all work done in concrete implementation and workgroup and come out with proposal we believe in.
  • The real work is delivering value for providers and patients. I think we made a huge first step here and I want to thank everybody for their work, particularly those in ironing out final proposal.
  • Next Steps:
    • We’re going to start focusing on three activities:
    • Documentation and Testing Workgroup
    • Reference Implementation/Open Source Workgroup
    • Implementation Geographies Workgroup
    • We will also continue work on Security and Trust WG
    • Previous workgroups’ work will get folded into others.
  • We’re going to ask each of the IG members to either help us out with developing the open source reference implementation or help to deliver real-world providers for exchange. What I’d like to see organizations do is to volunteer for each of the workgroups and then look at Implementation geographies and Security and Trust. I think security and trust will be focused on threat assessment and failure analysis of specification we’re looking at.

David Tao

  • Any more detailed descriptions for the workgroups? What do you mean by testing?

Arien Malec

  • We will put together a statement of intent for each of the workgroups.
  • Document and Testing – Put together specification, reference documentation and test set of specifications and work with reference implementation tool base.

Rich Elmore

  • Regarding the Individual Involvement workgroup, we talked about bringing that back around. We may want to say that this left for the moment, but we’ll bring it back in September.

Arien Malec

  • Yes, we will put a temporary rest on each of the workgroups. I would love for you to be involved in the Implementation Geographies WG– getting patients into real world exchange.

Doug Arnold

  • Is there a plan to share this collective wisdom with State HIE. In my experience, they are really clueless with what’s going on with NHIN Direct.

Arien Malec

  • Yes, I think it goes back to needing documentation. I’m going to be back in DC in a couple of weeks and that will be one of the actions that we’ll take on. I want to make sure that our state liaison has the right tools. I appreciate that.
  • I want to thank everyone involved in the process so far. It’s been a thrilling and sometimes difficult journey. I think we’ve come back to a good place.
  • We would like to reinvigorate this group around the four workgroups. I would like to thank everyone and look forward to next phase of this journey.
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Implementation_Group_Meeting_2010-06-29&oldid=457"