Implementation Group Meeting 06112010

Please feel free to send any corrections to the recording of your words in the notes to [AT nhindirect.org] or post these corrections to the wiki discussion tab.

Notes from the NHIN Direct Implementation Group

Date: June 11, 2010
Time: 9am-4pm
Attendees: Richard Elmore (Allscripts),Ravi Madduri (Argonne National Laboratory), Russell von Blanck (Atlas Development), Lin Wan (Axolotl), Didi Davis (Carespark), David McCallie (Cerner), Rob Wilmot (Cerner), David Kibbe (American Academy of Family Physicians and Clinical Groupware Collaborative), Vidit Saxena (eClinicalWorks), Kris Olberg (Emdeon), Tony Calice (FEI), Wes Rishel (Gartner), John Moehrke (GE), Paul Saxman (Google), Jason Colquitt (Greenway Medical Technologies), Nageshwara Bashyam (Harris), Tim Andrews (High Pine Associates), Michael Berry (HLN), Karen Witting (IBM), Christopher Ferris (IBM), Jeff Cunningham (ICA), Don Jorgenson (Inpriva), Jeff Peacock (Kaiser), John Theisen (Kryptiq), Malcolm Costello (Kryptiq), Lee Jones (MedAllies), Eric Heflin (Medicity), Seonho Kim (MedNet), Mark Stine (Medplus/Quest), Sean Nolan (Microsoft), Umesh Madan (Microsoft), Gary Teichrow (Mirth), Wenzhi Li (MOSS), George Komatsoulis (NIH), Carol Robinson (Oregon’s Strategic Workgroup), John Hall (Oregon’s Strategic Workgroup), Will Ross (Redwood Mednet), Charles Curran (RelayHealth), Gary Christensen (Rhode Island Quality Institute), Dan Kazzaz (Secure Exchange Solutions), David Tao (Siemens), Martin Prahl (SSA), Chris Lomonico (Surescripts), Tim Cromwell (VA), Brett Peterson (Visionshare), Paul Tuten (Visionshare), Rich Kernan (ONC), Jackie Key (ONC), Arien Malec (ONC), Mariann Yeager (ONC), Ioana Singureanu (ONC), Claudia Williams (ONC), Brian Behlendorf (ONC), George Beckett (TN State HIE), Dan Russler (Oracle)
Actions from June 11th

#	Date	Action	Status	Owner	Due Date
3	6/11/10	Address the objections raised during today’s discussion for each implementation option	Open	Concrete Implementation Teams	6/17/10

Actions from June 10th

#	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/1/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

Welcome and Agenda Overview from Arien Malec:
Security & Trust WG Update from Brian Behlendorf:

• Our goal is to build a lightweight, secure messaging system
• Trying to incorporate a IETF security review into our process
• Concepts like trust and security mean different things to different people
• The Security & Trust (S&T) WG came up with a consensus statement from the perspective of what attributes the final NHIN Direct solution should have

Walkthrough of S&T Recommendation provided by Brian
Section 1: Intent

• Not dependent on having a single organization at the center of NHIN Direct
• If two NHIN Direct users can trust each other, then they can configure a NHIN Direct solution to exchange information securely
• NHIN Direct messaging handling policy is similar to the idea of Fedex
• NHIN Direct users may have a variety of different message handling policies
• NHIN Direct users should have the right to scale up or down the networks that they are involved in
• There is not a single global, rooted trust - there may be multiple trust circles

Tim Andrews

• Think it is a big mistake to think of NHIN Direct like Fedex
• Arien Malec – This is an active topic of discussion within the Privacy and Security tiger team
  • There are a variety of levels of PHI exposure that a message handler may have
  • P&S tiger team is trying to define the best practices, policy rules of the road
  • We are saying that there is policy that governs the expectations that participants have and that participants should have the assurance that their message is being handled according to those message handling policies
• Tim Andrews – Recommendation says that we’re not providing for different levels of security
• Sean Nolan – We’re trying to distinguish between the policies of handling a message vs whether it is correct for providers to engage in exchange

Continued Walkthrough of S&T Recommendation provided by Brian
Section 2: Protocol Requirements

• Most important technical decision was to use x509 certificates
• Designed so that individual doctors don’t have to do key management, but can delegate this to other parties on their behalf
• The NHIN Direct software must allow for the configuration of multiple certificate anchors, which allows participants to define which trust circles they are part of
• We’re really just restating the case for using encryption
• This is about using public key certificates in the way that they should be used, allowing for multiple circles of trust

Ravi Madduri

• Do you have any standard in mind for credential delegation?
• Brian Behlendorf – The SMTP and REST teams both use the NHIN Direct agent, where on the sending side a server can digitally sign and encrypt on your behalf, while on the receiving side a server can also decrypt and sign on your behalf
• Arien Malec – Most predominant technique involves manual management of certificates

David Kibbe

• How would HISPs be able to examine the implementation of the security requirements by other HISPs?
• Arien Malec – For the purposes of the NHIN Direct early implementation activity, this will be done with a set of policy best practices (including certificate policy, privacy policy). Can’t speak to how industry participants will self-certify.
  • The model will likely move from self-attestation and mutual contracting to either an industry certification process or a level of Federal governance/certification.

Don Jorgenson

• There are situations where the key is not necessary, such as with the use of SAML assertions. Is x509 the only way to make security assertions?
• Brian Behlendorf – SAML is built on top of x509
• John Moehrke – There are two different layers of authentication. We’re trying to address the network layer, how one system authenticates to another system. When you get to how a user identity is asserted, SAML is appropriate.
  • SAML assertions are generally signed using PKI, so generally this goes back to a PKI infrastructure
  • SAML assertions would be used to deal with the endpoints, could use this for end-end security in NHIN Direct

Vassil Peytchev

• My understanding is that an intermediary can vouch that a source is who they say they are and the intermediary’s certificate can be provided to another party as a mechanism that the assertion is valid
• Brian Behlendorf – That’s correct if we mean that the source is the source endpoint and the HISP is the source HISP
• Arien Malec – This is allowed by technology, but may or may not be allowed by policy. Technology says that intermediaries with appropriate policy may manage trust on behalf of a source
• Vassil Peytchev – So then there is no requirement to have the message and certificate come from the same place.
• Arien Malec – Reliability needs to be defined by policy

Continued Walkthrough of S&T Recommendation provided by Brian
Section 3: Policy

• It is our goal that NHIN Direct protocols can be used in many policy environments
• Goal is facilitated by using x509 certs to proxy for policy adherence
• HITPC/ONC is expected to issue policy guidance for a base level of policy
• Similar to using browsers with root CAs, eventually there will likely be a common set of root nodes for healthcare exchange. However, we can’t decide this from the beginning
• Policy committees will need to address the question of what level of identity assurance will be required for NHIN Direct participants
• Intent is to ensure that whatever the policy outcomes are, NHIN Direct can enable them

Chris Lomonico

• What are the ground rules for getting a certificate?
• Brian Behlendorf – This is not within the scope of NHIN Direct
• Arien Malec – These are policy issues that will need to be defined within the policy framework
• Brian Behlendorf – What is relevant to the pilot phase in this?
• Arien Malec – The private organizations participating in NHIN Direct will need to agree on a policy framework to govern the early activity for NHIN Direct. This initial policy framework will not be provided by ONC. For certain federal partners, there may also be contractual agreements.
• Chris Lomonico – Will the CAs be responsible for managing certificate revocation?
• Brian Behlendorf – This should be left up to the implementation/local policy
• Arien Malec – We carefully designed a process and set of statements that did not address such policy considerations, we are leaving this question to the policy makers
• Brian Behlendorf – We should explain this in terms that are sufficient for the implementations to move forward for the pilot and for any policy implications to be surfaced

Malcolm Costello

• How would you regulate various types of messages from different sources, where some messages are less desired than others?
• Arien Malec – The trust model incorporates different levels of trust expectations for different classes of participants. Having multiple anchors of trust accommodates this. Many systems may want to implement specific address yes/no lists to accommodate such different needs
• Brian Behlendorf – One of the use cases we talked about is where entities may act as proxies for caregivers. NHIN Direct is about the transmission pipe, with local policies at the end points. In NHIN Direct overall, we’re leaving compliance with PHI and policy regulations up to the sender before they send a message.

Claudia Williams

• There are many issues that have been teed up to the NHIN Workgroup and P&S Tiger Team. From a process perspective, how are we communicating such issues back to these teams?
• Arien Malec – Dixie has surfaced many of the policy implications from the S&T recommendation back to the team
• Claudia Williams– The fact that you can have local policy decisions is a policy decision, and this should be called out
• Arien Malec – We’re trying to stay policy-neutral and yet we end up creating policy
• Brian Behlendorf – We’ve created a canvas that can be refined as policies are defined
• Claudia Williams– Sender needs to remember that they are responsible for that piece of the puzzle.

Concrete Implementation Team Presentations on Security & Trust:

XMPP – provided by Nageshwara Bashyam

• For client to server communication, XMPP uses SASL authentication
• There is also a TLS channel between the source and source HISP
• Between a server-server, the channel is negotiated using certificates
• Client certificates are distinct from server certificates
• The root CA must be the same between two servers
  • XMPP foundation runs an intermediate CA to generate certificates for XMPP servers
• Uses NHIN Direct security agent

REST - provided by Brett Petersen and Ravi Madduri
Brett Petersen

• Ended up with three teams in the REST implementation
  • Two of these teams had a similar approach to S&T
  • Argonne National Laboratory (ANL) implementation came up with a different approach
• Ruby on Rails/Java (Spring MVC) teams used the NHIN-D agent
  • Still some open questions around use of HISP-HISP TLS
• Arien Malec – Primary S&T model is the S/MIME approach. As explained by Sean yesterday, this also applies to REST approach

Ravi Madduri

• ANL is part of the group that developed the Globus Toolkit, which provides tools to organizations such as caBIG
• Implemented all NHIN Direct transactions by leveraging work from Globus toolkit
• Based implementation off of a scenario where a patient gives explicit consent for a provider to share information, using a SAML token
• Used x509 certificates for all actors and services
• Each entity can choose a set of CAs that they trust
• Data is sent over SSL
• Typical PKI, message signed by sender’s certificate and encrypted with recipient’s certificate
• Primary objective was to show the capability of SAML to accomplish authorization model
• Further enhancements could include notification, electronic patient consent, credential translation (high level services to perform these functions on the patient/provider’s behalf), automated trustroot provisioning, and HISP as a policy enforcer using XACML
• Implemented much of this for caBIG
• Decided to use REST to showcase a similar capability implemented using SOAP for caBIG
  • Surprisingly easy to do the REST implementation
  • Most of the work was in wrapping everything in a web portal
• ANL, as an academic institution, needs to figure out best model for engagement in NHIN Direct going forward

IHE/SOAP - provided by John Moehrke

• More detailed text can be found on the wiki around the IHE S&T approach
• Term policy is being used for different things
  • Policies are decisions, ranging from architectural decisions to more high level choices
  • We’re aiming not restricting a policy makers to only one choice
  • IHE allows policy makers to make choices, but we must help to constrain the choices that can be made. We must choose a reasonable set of policy options for policy makers to choose from and address these choices.
• IHE approach includes modular profiles, where you can specify a base and further constrain from that point onward
• If policy requires that you have end-end security, IHE has modular profiles describing how to do this. There is no reason to reinvent the wheel.
• In a push model, unclear where SAML assertions fit in. SAML assertions are more commonly used in a pull model.
• IHE has a consent profile where a patient can specify the restricted use of their health information. IHE also has a profile for provider attestation of clinical accuracy.
• Every approach has been able to meet the requirements of the security model

SMTP – provided by Sean Nolan

• The security agent was the only piece of code written by the SMTP team for S&T
• The agent is a piece of library code that if adopted, would be a part of the reference implementation
• Idea behind the agent is to make the base layer, working around perceived deficiencies in TLS
  • Supports simultaneous use of multiple trust anchors
• Three things need to come together for S&T
  • Private keys = Membership cards
  • Public certificates for each private key to allow exchange to happen
  • Anchor certificates
• ONC may someday identify one single set of policies, one authority for all providers
• Organization like Markle may do this for PHRs
• If there are no national authorities available, for PHRs or providers, two entities could exchange certificates from separate trust anchors
• There is a concern that DNS can be spoofed, but this is likely not a issue for us
  • Because we have a second layer of trust-checking, you could only be spoofed by someone that you trust
• DNS scales well, the end tools available generally don’t support certificates
• Walkthrough of how agent works for sending and receiving a message

George Komatsoulis

• Relevant to all security models: From the standpoint of non-repudiation, we need to get down to the level of an individual within an organization. This impacts the granularity of the certificates. Is this a policy decision?
• Arien Malec – This is a policy decision. We came up with motivating use cases for a organization address as opposed to an individual address
• George Komatsoulis – At the end of the day, a document comes from somebody
• Peter DeVault – A document could be automatically generated as the result of a workflow, with no individual involved
• Arien Malec – A covered entity may not be an individual provider

Dan Kazzaz

• When you sign something with your private key and your private key expires, what happens when you need to look back at a document?
• Umesh Madan – What comes into the agent is an encrypted signed message, what comes out is plain text.
  • We can address this situation by signing with multiple certificates
• Arien Malec – Would be good to keep the signature around
• John Moehrke – Different signature policies are based on the intended use of the certificate. There are inherent management issues around the use of certificates.
• Dan Kazzaz - A certificate can appear in many different forms, as a group we need to come up with a clear definition of what’s in a certificate and publish this as an implementation guide.
• Arien Malec – You can point back to existing specifications, point to RFCs, etc.

Tim Andrews

• Has anyone talked with a CA about the liability of doing this?
• Arien Malec – We’ve never assumed that the root of trust would become one of the well-known roots. Likely that the CA would be a health-related entity.
• Sean Nolan – We talked to some CAs and they seemed interested
• Arien Malec – We would use a different CA than the CA used in your browser bundle

Vassil Peytchev

• Could you address the threats entailed by the use of DNS to map NHIN Direct addresses and use of DNS in the agent?
• Sean Nolan – Based on our analysis around these threats, we believe that the secondary check of the received certificate against configured anchors mitigates threats like spoofing
• Arien Malec – In the REST implementation, if you ensure that the transaction occurs over TLS, you have an additional level of reassurance.

Michael Berry

• Understand the benefit of using DNS, it has an already deployed infrastructure, reliability, and is distributed. But if we’re relying on ONC/a vendor contracted by ONC, what would be the impact of distributing certificates using LDAP?
• Sean Nolan – Wouldn’t personally choose LDAP to distribute certs, but would use for a directory
• Umesh Madan – Note that the agent code is not tied to DNS

Comprehensive HIE WG Update from Vassil:

• Comprehensive HIE WG began by mapping IHE/NHIN Exchange transactions to the abstract model
• User story group will work from the comprehensive HIE scenarios defined by the Comprehensive HIE WG
• Overview of “Karen’s Cross” diagram
  • Identified clear points of interaction between NHIN Exchange and NHIN Direct that need to be addressed
  • When looking at different requirements for NHIN Exchange/NHIN Direct, there need to be certain conversions: transport, metadata, and trust/security (this is policy issue)
• Defined key terms for comprehensive HIE exchanges
  • Full capabilities HIO – HIO that supports full set of NHIN Direct core user stories/services
  • Partial capabilities HIO – HIO that does not support full set of NHIN Direct core user stories/services
  • Notion of “belonging” to a full capabilities HIO – full HIO can refer to many types/sizes of organizations
• Goal of comprehensive HIE interoperability is to not create two separate networks (NHIN Exchange and NHIN Direct) that seek to accomplish the same thing
• Technical capabilities of NHIN Exchange can allow for interaction with a full HIO
• Overview of conversions that are included in Karen’s cross
  • Step-up transform – NHIN Direct source to a destination within a comprehensive HIE
  • Step-down transform – Source within a comprehensive HIE to a NHIN Direct destination
• In the scenario where a full capability HIO sends to a destination without a full capability HIO, if there is no conversion, there is no interoperability
• Step-up conversion may occur where there is a NHIN Direct source sending through a source HISP, which performs the conversion, to a NHIN node.
  • Could also occur where a NHIN Direct source sends to a NHIN node, which performs the conversion.
  • NHIN node may not necessarily need to perform conversion
• Step-down conversion may occur where a source within a NHIN node, which performs the conversion, sends to a NHIN Direct destination.
  • Could also occur where a source within a NHIN node sends to a destination HISP, which performs the conversion, sends to a NHIN Direct destination.

Arien Malec

• As Vassil pointed out, the definition of a full capability HIO states that all of the NHIN Direct use cases are fully satisfied within that organization. This could be DoD, VA, Kaiser, etc.
  • These use cases are satisfied within a workflow in the organization.

Eric Heflin

• NHIN Exchange exists and is in use today. You must implement the IHE protocol to interact within NHIN Exchange. Our decision is really are we choosing one protocol (IHE) or two (IHE and something else)

Rich Kernan

• Not all transactions for NHIN Exchange/NHIN Direct will be used by all groups
• Many services that could be used for NHIN Direct have not yet been added to NHIN Exchange

Brett Peterson

• The diagram seems to show that the NHIN node is exposing itself to NHIN Direct using the full HIO
• Vassil Peytchev – Should clarify diagram to show that the NHIN node is not part of the full HIO

Lee Jones

• Every time I hear someone speak about NHIN Direct who is not part of this group, they believe that it’s exclusively point-point and that NHIN Exchange is separate. Are people expecting a us to produce a solution for how Karen’s cross can be accomplished?
• Arien Malec – A number of federal partners are demanding that NHIN Direct and NHIN Exchange work together due to the investment they’ve already committed to NHIN Exchange.
  • State HIEs also want clarity on how the two will interoperate.
    • We want to make sure that 1) we’re not creating a divergence/alternate path and 2) we define how record locator services may work with direct push
• Lee Jones – So we don’t need to have a solution for how to solve Karen’s cross?
• Arien Malec – As a federal partner, you don’t want two ways for messages to be sent to your providers.

David Tao

• Is there a significant difference between the step-up/step-down shown here vs what the IHE team described yesterday for their implementation?
• Vassil Peytchev – NHIN Exchange uses XDR, like the IHE implementation. If we are stepping up/down to XDR, that part is the same. The question is the level of metadata being exchanged.
• Arien Malec – This relates to each organization’s policy. Each organization may have different in-bound message handling policies describing how much step up/down is required.

David McCallie

• If a core goal of NHIN Direct is to create simple and easy universal addressing, I suspect that this may happen more rapidly than the widespread roll-out of HIEs.
• We shouldn’t have data-sharing capabilities be a requirement for participation in NHIN Direct.
• There are sharing models that don’t use NHIN Exchange protocols. These organizations will have to support a NHIN Direct entry into their system.
• I see NHIN Exchange and NHIN Direct as parallel worlds. The interoperability between these two should be seen as an optional value-add, but isn’t necessary to the core mission of direct exchange.
• Vassil Peytchev – To address the first question of HIEs that don’t use IHE protocols, they will have to do custom matching.
  • To address the second question of parallel worlds, we will still have to figure out how a full capability HIO would be able to share with a NHIN Direct destination.
• David McCallie – Would envision that NHIN Direct services could be used for this
• Vassil Peytchev – There shouldn’t be a separation at the workflow level between Direct/Exchange transactions
• Arien Malec – We’re more concerned about meeting provider expectations about having a single workflow, regardless of information source
• David McCallie – There are separate decisions between sharing outside of a HIE and publishing within a HIE
• Arien Malec – Vassil is saying that within the walls of a HIE, they can have whatever policies they want, but they shouldn’t have to use a different workflow than their existing workflow to send via NHIN Direct

Concrete Implementation Team Presentations on Comprehensive HIE:

SMTP – provided by David McCallie

• I see NHIN Direct and Exchange as parallel protocols, with both being necessary for HIE
• NHIN Direct should be used for side-effect free, private messaging, whether a provider is part of a HIE or not
  • There are situations where a provider may have no connections to a HIE or a provider may have connections multiple HIEs
• There could be interaction between Direct and Exchange in certain scenarios. XDM provides a good mechanism to bridge the two.

REST - provided by Brett Peterson

• Axiom 1: A large majority of push-based communication will not need to involve a NHIN Exchange endpoint
• Axiom 2: Critical use cases do involve interaction with NHIN Exchange (ex: CMS)
• REST team designed for Axiom 1 to avoid the complexity of Axiom 2
• Need to a figure out how to perform this interaction
• Arien Malec – The IHE team prototyped these transactions
• Brett Peterson - A NHIN Exchange node would expose itself as a HISP & a NHIN Direct address
  • Addressability piece is a critical part of the puzzle

XMPP – provided by Nageshwara Bashyam

• In use cases where NHIN Exchange interactions would occur, there would need to be step up/down services to support different potential endpoints

IHE/SOAP - provided by Janet Campbell

• We should focus on the importance of NHIN Exchange/Direct interoperability
• If we do believe this is important, we should just do the work once and minimize the conversion points by choosing XDR for the backbone
  • The work to perform a transaction between NHIN Direct and Exchange would already be done if XDR was chosen as the backbone
• Should consider other architectural concerns, including phonebooks, trust anchors, and people
• When we talk about the IHE implementation, SOAP is the protocol and XDR is the profile.
• IHE already has a documented process, testing, language accommodation, implementation guides etc
• It’s easier to take what’s already been done, and only use what’s needed, then later add more as needed

Q&A
Lin Wan

• Content is more important than transport for many vendors. Metadata is important for system processing. Manual management of different types of messages (healthcare vs non-healthcare purposes) increases cost.
• Arien Malec – Metadata transformations are harder than transport transformations
  • Not all unstructured messages are irrelevant to healthcare, there are valid situations where these messages may be transmitted for healthcare purposes.
  • There are cases where there are small providers whose systems cannot produce metadata.
• Lin Wan – In many of the scenarios we’ve looked at, the source produces the package. An EHR can do this. Is the case Arien described a case we really must accommodate if MU is moving toward EHR adoption?
• Arien Malec – There is an assumption that at least one participant in the exchange is trying to achieve MU, but it’s not necessarily true that both participants in exchange have a system that is certified to perform these transactions.

Tim McNamar

• Need to have one common address, as with Surescripts.
• Arien Malec – Let’s table this question, as it is not relevant to the discussion.

Claudia Williams

• As we’re thinking about the HITSC requirements, we need to keep in mind the importance of simplicity
• There’s a reason that we pursued NHIN Direct, not everyone is ready for more complex exchange
• There will be heterogeneity between how people do things but there needs to be a way to bridge between these

Jeff Peacock (via Live Meeting)

• Hear, hear! Also, those of us with EMR's are reluctant to fall back to unstructured data because it becomes much less useful for patient care. Even pdf's and images should be sent as part of a structured CCD message.

Karen Witting

• We really want one NHIN. NHIN Exchange refers to what already exists in NHIN Exchange, which is SOAP and web services.
• Federal partners will want communication using SOAP and web services. There will need to be a transformation to this if a different protocol is chosen.
• The existing NHIN Exchange has adopted a XDM metadata model. If you choose a different metadata model, you will need to be able to convert to this.
• NHIN Exchange uses XDR for push transactions.
• There is confusion about the need to do things in two separate ways. If there is no way to transform between Exchange and Direct, then at least one side of a transaction will need to be able to support both.
• If we don’t want choose XDR, we will need to do conversions.
• There is a lot of support for NHIN Exchange, as it has been adopted by many organizations already.

Eric Heflin

• Many states have created architectures based on NHIN Exchange and are wondering about the impact of NHIN Direct.

Chris Ferris

• Many of the presentations are focused on the protocol, but the real issue is what you’re pushing, the interoperability of the payload
• How is a HIE supposed to do something meaningful with unstructured documents?
• Suggest that we focus on starting a base amount of metadata to promote interoperability
• Arien Malec – Transport is important because most providers use fax today, even those who have EHRs, because there isn’t an obvious, standard way to exchange electronically
  • There is a tension between the need to optimize for small provider participation and also to have rich, structured data that allow for semantic interoperability
  • One side says don’t do it if you can’t do it right, while the other says just get the exchange set up and progress toward more complexity as providers demand more

John Moehrke

• The IHE group is not saying, you have to XDR anyway, we’re just saying start small. Know that NHIN Exchange exists and let’s head in that direction.
• For clarification, it should be noted that NHIN Exchange has multiple modes for exchange, but there is no XDS except within edge systems.
• We’re focusing on the small provider to small provider scenario, but we must recognize that this small provider may be sending or receiving with a larger partner

David Kibbe

• Feels bullied by IHE group – do it our way, or don’t do it at all
• In the real world, there are different ways to do things and to accommodate these different ways
• Arien Malec – We should assume good intentions. I interpret the IHE team as giving a value statement for choosing XDR. We should think about teams’ statements in terms of stating such values.

Concrete Implementation Discussion and Decision:
Arien Malec

• We should be able to agree that we all share the same values, though we may prioritize these differently

Brian Behlendorf

• We want to get to a scenario where the majority of doctors use sophisticated EHR technology
• NHIN Direct is proposing something broad-based that will eventually get us toward this vision
• Both NHIN Exchange and NHIN Direct are providing ways to move us in that direction
• We need to give enough to the implementation team to get the pilots underway

Nageshwara Bashyam

• All of the teams have done a good job, all of the protocols could work
• XMPP may be a bit ahead of its time for what we’re trying to accomplish today
• Rather than have the group discuss XMPP further today, we’ll try to advance XMPP outside of this project in the industry
• Brian Behlendorf – The CONNECT team is experimenting with XMPP
• Arien Malec – Perhaps 10 years from now we’ll have presence, asynchronous and synchronous communications built in every EHR

Brian Behlendorf

• Required a lot of heavy-lifting to get CONNECT to where it is
• Acknowledge that it is a challenging software to use
• We’re trying to pick the proposal that we can feel comfortable with and acknowledge

Arien Malec

• Everyone should put on the table their willingness/unwillingness to support each proposal and if they are unwilling to support a particular proposal, what fixes are needed in order for them to support it
• Round the room for each organization

Allscripts – Richard Elmore

• There are two vitally important goals for NHIN Direct
  • Email exchange nationally
  • Automated exchange with EHRs
• Can’t choose one over the other, we need to meet providers where they are today and also acknowledge that we want to move toward EHR use
• IHE/SOAP – First choice, XDR backbone seems like the best way to get to automated exchange with EHRs
• SMTP – Second choice because it would enable email exchange nationally
• Arien Malec – Are there any approaches you’re not prepared to support?
• Allscripts - REST – Not best suited to achieve these goals. Not convinced that REST can achieve rapid email adoption.
• Arien Malec - If the REST team can show widespread access to participants with email clients, would Allscripts be able to support REST?
• Allscripts - Yes, and if they can also support interaction with IHE

American Academy of Family Physicians – David Kibbe

• Willing to support SMTP or REST, but not IHE
• Don’t want to have to fix IHE
• NHIN Exchange will exist in the ecosystem, but would like to see them accept a simpler form of communication
• Arien Malec - Sounds like you value simplicity. If they can address the issue of simplicity, would you be prepared to accept IHE?
• AAFP – Don’t think we could, the IHE protocol is the least broadly accepted in comparison to REST/SMTP
• Arien Malec - What aspect of simplicity do you feel IHE does not portray and what would need to be fixed?
• AAFP – Need to address complexity at the HISP level, only very large organizations could use IHE. A HISP needs to meet customers’ needs where they are now while offering a path to more sophisticated data services.
• Brian Behlendorf – Would you be willing to participate in a process that would try to define what a HISP-in-a-box that could enable simplicity would look like?
• AAFP – Not sure. The organization would look at any such proposal with open eyes.
• Arien Malec – Will note that lowering the cost of HISP implementation and deployment as key thing for IHE team to fix
• Steve Waldren for AAFP – Wants to see IHE address the separation of metadata issue
• Veto for IHE (David Kibbe vocalized this separately after the discussion)

Argonne National Laboratory – Ravi Madduri

• Willing to support IHE or REST
• Don’t understand SMTP’s ability to meet security requirements
• Arien Malec – Will note that you want SMTP to address the full security model in a way that gives confidence

Axolotl – Lin Wan

• Willing to support all protocols
• All implementations have some issues that need to be addressed
• Concerned about having good content and metadata
  • SMTP may the simplest/quickest way to get us there, but it sets the bar too low for data and may not address error handling comprehensively
  • Need to understand how REST handles error, retry
  • IHE needs to address patient-specific nature of XDR
• Also concerned about delivery of content

Carespark – Didi Davis

• First preference is IHE because it has clearly defined ways to connect our current business associates, we would be able to roll this out the fastest
• Also support SMTP and REST, if step up/down procedures for interaction with NHIN Exchange are clearly defined

Cautious Patient- Fred Trotter

• (via Live Meeting chat) We are only discussing the core exchange protocol and we want lots of variance in the Node/HISP to user connection. We have a strong preference for generalized messaging. We actually think XMPP is a better protocol because of the presence thing, but SMTP gets our vote. SMTP will get the fastest adoption. IHE is too complex. However, the IHE team has made its case that lack of a pathway to and/or lack of compatibility with NHIN Exchange could create significant balkanization. The "solution" for IHE is to partner with NHIN CONNECT to make a bridge reference project. So to "fix" IHE we just move it out of the "core". We feel that REST is a development protocol and not a messaging protocol. The hidden cost of REST is that you have to build a messaging protocol out of it. The security implications of that are staggering. You could fix REST by borrowing heavily from SMTP/XMPP for operational design, which is already happening to a certain degree. I actually do not think XMPP needs fixing at all, it is a better messaging protocol than SMTP and is easier to strongly secure. We place it in second place, only because it is not as widely understood by business IT as SMTP. Fixing it can only happen by making it more popular, it would be made more popular by NHIN Direct choosing it ;) . There is no protocol choice that NHIN Direct that could cause Cautious Patient to not participate.
• Strong preference for protocols that have messaging built in
• Overall, would prefer SMTP or XMPP, then REST, but there is no protocol we would not support

Cerner- David McCallie

• Wouldn’t rule out any approach and would support anything
• See SMTP as the fastest way to get us where we want to be
• Second choice is IHE, given that it is based on a proven code base
  • IHE should address simplicity issues around metadata and implementation
• REST is appealing in terms of simplicity, but concerned about reliability of the delivery model

Clinical Groupware Collaborative- David Kibbe

• Feel strongly that REST is the best protocol because it would be best suited to web services development over time
  • Writing new code is not necessarily a bad thing and might be a way to quickly innovate
• Willing to accept whatever the market accepts
• Veto for IHE (David Kibbe vocalized this separately after the discussion)

eClinicalWorks – Vidit Saxena

• Most strongly support IHE, but would implement the consensus decision
• Agree with Axolotl on concerns

Emdeon – Kris Olberg

• Will support the consensus

Epic- Peter DeVault

• Prefer the IHE approach for the backbone and would support other protocols on edge
• Preference in order: IHE, REST, SMTP
• From the perspective of Epic’s many clients, there is a lower implementation cost to use IHE as the backbone and REST is also preferred
• Will support whatever decision is demanded by customers
• Feel that Epic’s customers will be disappointed if messages do not have enough metadata to be integrated into their existing workflows
• Even if REST/SMTP is chosen, these teams should ensure that there is a path to having useful metadata

FEI – Tony Calice

• Like the idea of XDR as a backbone and believe that providers would support SMTP
• Willing to support anything that gets rolled out

Gartner – Wes Rishel

• If we choose NHIN Exchange [IHE], would it be the complete suite of services?
• Arien Malec – No, it’s what’s described in the IHE capability worksheet, just XDR
• Gartner - So it is a SOAP push model
  • Would be willing to support all three options
  • There needs to be capability to stand-up a baseline HISP without HISP access to PHI
• Arien Malec – XDR does require access to some patient-specific metadata
  • Personally confused by the level to which it’s required within IHE to have access to patient data
• Gartner – The base level HISP should not have access to protected health information. Does the baseline have to provide NHIN step up/down? If so, then it would have to have access to PHI.
• John Moehrke – When you’re asking this question, are you asking it in the context of a pure XDR environment or an environment where there are different edge protocols? If you choose XDR end-end, there is no need for HISPs.
• Gartner - If the proposal says that step up/down is a value-added service that a HISP may provide with a business associate agreement, then I’m fine with it. Don’t want every HISP to have to have business associate agreements with every organization it communicates with.
  • Of the three proposals, SMTP will get us there the quickest
  • Many of the security solutions are identical, so it choosing SMTP wouldn’t preclude us from building security for other protocols in the future
• Don’t have a sense of the relative skillset needed to build a HISP with SOAP, IHE team should address this

GE - John Moehrke

• Clearly would prefer IHE, but recognize that this would require small docs to have a EHR
  • We shouldn’t be driving this decision, we should give small docs choices
• Between SMTP and REST, both have promise and problems. Believe that all of these issues can be solved.
  • Would like to see the use of XDM model
  • Suggest to SMTP group that they support S/MIME

Greenway Medical Technologies - Jason Colquitt

• Easiest path for Greenway would be IHE
• Next order of preference would be REST, SMTP

Harris- Nageshwara Bashyam

• Will support any implementation that is picked

High Pine Associates- Tim Andrews

• Mostly here to represent states
• Will support whichever protocol, but would prefer IHE based on fact that this is what the industry is using
• Biggest issue is when will products be available - we need to have products ready fast (in 6-9 months)
  • There are IHE products available today
  • Don’t believe this would be achievable for REST/SMTP
• Arien Malec – It would be interesting to ask this question to the EHR vendors in the group

HLN – Michael Berry

• Also involved in advising state HIEs
• Wouldn’t want to see a future with less metadata and more human labor, but acknowledge that IHE is complex
• Will support any of the protocols, but believe that SMTP best meets needs of simplicity and speed
  • SMTP should look at use of LDAP
• Also concerned that we need to have a product available fast

IBM- Karen Witting

• All of these protocols will work, it’s a matter of preference
• I have been fighting for one NHIN, we should have only one way to do one thing
• For all protocols, want to see a mapping between NHIN Exchange/Direct, metadata, flexibility for security and privacy, and speed of getting to a product
• Do not value simplicity because definition of simplicity is murky
• SMTP - concerns about message only going where it is designed to go and security vulnerabilities
• REST – overall spec needs work, especially around security and reliability, time to market will be slow
• IHE – need to work on minimal metadata and be more accessible on the edge
• Would support anything that can be rolled out quickly and support metadata in an extendable way
  • If we support SMTP, need to look at use of XDM package
  • Concerned with REST, but would be willing to support it

ICA- Jeff Cunningham(via email)

• REST is acceptable - about as simple as SMTP but much more extensible
• IHE/SOAP is acceptable - already established and can reasonably work with simpler protocols
• SMTP is not acceptable - simple but not extensible enough to serve as backbone protocol
• XMPP is not acceptable - great edge protocol, but not implemented enough in the current vendor base to serve as the backbone. Also, I think at scale more adaptors and implementation standards protocols would need to be established to make this work.

Inpriva- Don Jorgenson

• If we look at SOAP, rather than IHE, SOAP has a good security model for healthcare
• Will support any protocol

Kaiser- Jeff Peacock

• We need to support structured data and define a pathway for using this structured data
• Don’t think we should look for an easy on-ramp that doesn’t go anywhere
• Willing to support all, but SMTP seen as the weakest

Kryptiq- John Theisen

• Would support all, preference for REST

MedAllies- Lee Jones

• Personally think about term the simplicity as referring to expediency
• Technical simplicity and technical implementation are the gateway factor for widespread adoption
• Concerned that NHIN Direct is a great opportunity to move the needle and if we focus too much on the lower-ability providers, we risk vendors taking their own path
• NHIN Direct needs an organization to maintain specifications, test bed, etc – IHE already has this
• For expediency’s sake, we endorse IHE, with the caveats that have been mentioned previously
• Worst situation would be for the country to stall
• Want to see HISPs commit to being part of the network and having IHE and other protocols supported by HISPs
• Would only support the other protocols if IHE was also supported as the backbone

Medicity- Eric Heflin

• NHIN Direct shouldn’t create a solution that is a parallel effort to NHIN Exchange
• Interoperability is our key value and IHE is the best way to achieve this
• Preferences are IHE then REST, cannot support SMTP
  • REST is too simple - should address reliability, lack of metadata, testability
  • Cannot support SMTP because there is a workflow danger for providers and don’t like the need to install the security agent

MedNET – Seonho Kim

• Would endorse all four protocols, with preference for IHE, then REST, then SMTP, then XMPP
• Reservations with SMTP around security and metadata

Medplus/Quest- Tom Wagner/Mark Stine

• Would endorse XDR, a single protocol makes sense
• Share concerns about IHE regarding metadata and as well as with ATNA
• Would like to see REST/SMTP on the edge

Visionshare – Brett Peterson

• Will support all three protocols
• Need speed to get to wide implementation
• Large organizations are already well served by IHE, we now need to address small providers
• Order of preference: SMTP, REST, then IHE
  • Would like to see NHIN Exchange interaction addressed by SMTP/REST
  • Would like IHE to address complexity of implementation by potential HISP developers, need better documentation

Microsoft- Sean Nolan

• Would be difficult for Microsoft to move forward with IHE. To support IHE, would need to see how:
  • IHE could support multiple circles of trust
  • IHE could provide sufficient services to providers in a commercially sustainable way by 2011
• Strongly support SMTP and would also support REST
  • REST problems could be fairly easily addressed

Mirth- (Arien speaking on behalf of Mirth)

• Mirth has expressed that they will build anything

MOSS - Wenzhi Li

• The HISP-HISP protocol should be sophisticated enough to support interaction with NHIN Exchange
• Believe that all four protocols should be provided as an option on the edge
• Would support all, with a preference for XDR as the backbone and SMTP on the edge

Surescripts - Chris Lomonico

• Primary choice is REST, but would support all
• Neutral on any needed fixes

NIH - George Komatsoulis

• Preference for REST or IHE
• Would support all

Oracle – Dan Russler

• Already support all protocols

RelayHealth- Charles Curran

• Willing to support all, preference for IHE

Oregon - John Hall

• Would prefer REST, for the reasons Sean outlined, but could support all

Redwood MedNet – Will Ross

• Can support all
• Would like IHE to acknowledge that if they could already support small providers, there wouldn’t be a NHIN Direct

Rhode Island Quality Institute- Gary Christensen

• Will support all
• Most important criteria is ease of integration into EHR processing

Secure Exchange Solutions- Dan Kazzaz

• Prefer SMTP, because it is the cheapest, easiest to deploy, and easiest to integrate in the workflow
  • For those who do not have EMRs, SMTP is the easiest to use
  • Important to be payload-agnostic, SMTP is good for both backbone and edge
• To fix IHE, would ask them to come closer to X12 and HL7
• Would support both REST and IHE

Siemens- David Tao

• Both IHE and SMTP have strong merits, IHE is first choice
  • IHE is the best upward bridge, but we cannot do IHE alone
  • There is a need for SMTP
• Would support IHE as backbone and SMTP as the edge protocol
• Would also support pure SMTP on both backbone and edge
• Could support REST but this would be a lower preference
  • Some of the simplicity of REST may be lost since we’d have to build so much onto REST for healthcare
• SOAP has already addressed healthcare needs to a large extent

SSA- Martin Prahl

• Would be willing to support all protocols

TN State HIE – George Beckett

• All the protocols have issues
• See NHIN Direct, a one-to-one push, as slowing down the state HIE’s goal to allow for query transactions across the state
• Would prefer IHE, but also would support SMTP
• Would not support REST simply by process of elimination

VA- Tim Cromwell

• Will support all three
• Should consider changing term “doctors” to “clinicians”

Arien Malec

• IHE teams should address:
  • Documentation, skinny it down so that a developer can pick it up and implement it
  • Need to identify a minimal set of metadata that is required for routing and to separate this from the content package
  • Currently, only way step up/down works involves a peek at the content metadata
• SMTP should address:
  • Email clients need to be locked down due to concerns around the risk of having secure and non-secure addresses used from the same client

Brian Behlendorf

• Even though there was a majority support for XDR at the backbone, it also produced a great deal of vetoes
• If IHE were chosen, the IHE community would be on the hook to make implementation easy for a HISP
• Proposed strawman:
  • XDR at backbone, carrying XDM, with a minimum set of tools
  • When REST was discussed, the majority of arguments tended to be in favor of REST on the edge
• When it comes time to building the pilots, let’s focus on building REST at the edges
• Propose to also have a team build an optional SMTP plug-in for HISPs that could connect with other NHIN Direct nodes

Arien Malec

• Don’t know if we could use XDR as it is currently profiled, but perhaps a new SOAP-based profile that has the ability to get from A-B without overly complex packaging would work
• There are enough vetoes on XDR to make this path difficult for many to swallow

Google – Paul Saxman (late vote via email)

• In the near-term, Google would be willing to support the REST and Email implementations, with a preference for REST. All three implementations have their strengths and shortcomings that would need to be addressed within the next year, but it's Google's belief that the simplest solution, which allows for easy integration into the network without sacrificing security or functionality, is the best. The IHE implementation would make integration considerably more difficult without providing additional end-to-end capabilities per the NHIN-D user stories.

Lee Jones

• For the purpose of proving this out, we may want to consider multiple protocols, though we’d thereby create a more complicated HISP

Janet Campbell

• To address the concern expressed about doing step-up without revealing PHI, note that the IHE team did a step-up demonstration where PHI was not revealed

Eric Heflin

• There is interest in IHE to make things easier, quickly
• This could be accomplished by creating implementation guides, having self-contained documents, architectural overviews

Wes Rishel

• Many different points of view have been stated today
• Must be able to both facilitate EHR adoption and also support simple exchange between providers

John Moehrke

• Should be noted that NHIN Exchange is a SOAP exchange, with a security model and metadata model
• I can acknowledge that if XDR is not meeting our needs, then we need to go to the beginning and ask what we want to accomplish and build from there
• There is a theoretical purity expectation, reality is that you have to have both pull and push

Gary Christensen

• We’ve been focusing on HISPs, but what are the ramifications for what happens in doctor’s offices?
• Arien Malec – Fastest path if I’m going to delay buying a EHR is to use a web browser or an email client.
  • Fastest path if I have an EHR is using XDS.b with some modifications.
  • Fastest way to get to middle ground is unclear
• Peter DeVault – Agree that if there are people who don’t have EHRs, email/web browser is easiest. But, we need to keep in mind that they may be communicating with people who do have more sophisticated technology. Our goal for the pilot is to build a HISP-in-a-box to demonstrate that this can be done.
  • Also should be noted that we didn’t propose that the end-end solution should be XDR, we showed that a lower-technology solution should be on the edge.

Arien Malec

• Note that Brian’s strawman proposal is a first suggestion. If IHE could produce a SOAP-based protocol that is similar to XDR, but much simpler, and implemented SMTP or REST on the edge, would this switch a no to a yes vote?

• Sean Nolan – Would want to see a profile of who will purchase and run the HISP-in-a-box
  • Need to specify the requirements for a HISP in a box
  • Look at who serves small businesses today, it’s not Microsoft, Epic, or Cerner
  • Only can think of 3 constituents: state HIEs, existing ISPs, and ?
  • We need to outline these capabilities and see if we’re serving their needs
  • Microsoft cannot support IHE today, we would not move forward with the pilot process
• Arien Malec - Also many practices are supported by VARS which support their practice management vendor
• Sean Nolan – This boils down to a ISP

Arien Malec

• Each organization should type up a list of objections for each concrete implementation team and each team should seek to address these

Tim Andrews

• There is a business model of selling to some small docs
• Sean Nolan – But there are many docs for whom this is not working

David Kibbe

• I think that we’re building toward NHIN Exchange light, not NHIN Direct. This would be good for large organizations and the consulting firms that work with them. Would not be good for small providers who do not have EHR technology
• AAFP will not participate in the NHIN Direct pilot under current circumstances if IHE is chosen
• Real need is to provide a connectivity solution for small-medium practices in the very short term

Arien Malec

• Each team should take the list of objections and address them
• Disappointed that we have two proposals that each could go forward with 90% support, but that each has a strong 10% opposed

Brian Behlendorf

• Some objections that have been stated are not factual, but are value-based or incorrect
• Consensus does not mean uniform agreement
• Understand concern that we’ve over-anchored around one suggestion and that we are putting the IHE team on the hook
• The crowd that supports SMTP can build an alternative SMTP-based approach

Claudia Williams

• We set a goal and assumed the best of intentions
• We’re at a point where we need to take a step back to reflect and do analysis
• Confident that we’ll find a path forward

End of notes, though meeting continued after this point