Concrete Implementation Agenda & Notes from 06082010 Meeting
Jump to navigation
Jump to search
Date: June 8th, 2010
Time: 11am-1pm and 2pm-4pm EST
Attendees: Jackie Key, George Cole, Steven Waldren, Ravi Madduri, Didi Davis, David McCallie, Greg Meyer, David Kibbe, Janet Campbell, Vassil Peytchev, Peter DeVault, Matt Potter, Nageshwara Bashyam, Noam H. Arzt, Karen Witting, Don Jorgenson, Matt Koehler, Parag More, Vince Lewis, Eric Heflin, Mark Stine, Umesh Madan, Sean Nolan, Arien Malec, Brian Behlendorf, Dan Kazzaz, Martin Prahl, Chris Lomonico, Brett Peterson, Fred Trotter, Nathan Hogge, George Komatsoulis, Christopher Moyer, Lin Wan, John Moehrke
Actions for this Week:
Live Meeting Link:
[1]
Note: we really want every team to hear every other team's presentation, and ask questions & give feedback, and be a part of the consensus decision, because ultimately we are one team and will be working on a single implementation. For that reason, we are not posting the schedule of presentations in advance.
Presentation Materials:
XMPP Presentation from 6/8/2010 Extended Session:
REST Presentation from 6/8/2010 Extended Session:
SMTP Presentation from 6/8/2010 Extended Session:
IHE Presentation from 6/8/2010 Extended Session:
Notes
Comment from Brian Behlendorf
· Goal is not come up with a single proposal, but to come together as one team as agree upon one or more options to move forward with
· Overview of “Rules of the Road” for today’s presentations
· Each team will have an hour to present and take questions
Comment from Arien Malec
· Let’s speak openly and honestly, but without rancor
XMPP Presentation and Q&A ''– given by Nageshwara Bashyam
· XMPP meets the goals of the NHIN Direct project, providing simple, direct, secure, and scalable transport
· XMPP can support features beyond basic NHIN Direct functions to support the creation of innovative healthcare applications
Question from Arien Malec
· To what extent can these innovative features be disabled if they’re not needed or desired?
· Nageshwara Bashyam – You can configure certain features as needed, but some features cannot be turned off.
Question from Ravi Madduri
· Through experience, I have found it hard in a hospital environment to get ports open. XMPP seems to require open ports. Do you see any difficulties with this?
· Nageshwara Bashyam - For client to server communication, you can use HTTP binding. Not sure if you can use a HTTP port for server-server.
o Not every vendor can support these functions
Question from David Kibbe
· As a physician I’m excited about having instant messaging available
· Struck that when you define simplicity, you define this from a developer’s perspective and not a end user’s perspective. Simplicity should be defined from the end user’s point of view. How would XMPP allow for this?
· Nageshwara Bashyam – You can use java libraries and integrate with an email client
· David Kibbe – If we’re depending on developers to develop the clients for the physicians and their patients, then we’re talking about something in the future.
o In the present, we need to talk about using existing web-based email clients where the physician will not need to acquire additional technology. We shouldn’t put a burden on end users beyond what they currently have in their offices.
o Development responsibility here is on the EHR vendors. This is exciting, but will happen in future if the first level is successful
· Nageshwara Bashyam – XMPP is not as prevalent in the industry as some other mechanisms.
· Brian Behlendorf – Note that there are web-based XMPP clients
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· XMPP uses address that are similar to email addresses
Questions from Arien Malec
· Are you assuming mutual TLS? Does that assume a single trust model?
· Nageshwara Bashyam – Will address security in the next slides
· Arien Malec – If you don't send presence stanzas, does out of band file transfer work anyway?
· Nageshwara Bashyam – Typically the communication allows the client to keep retrying
· Arien Malec – Presence is a nice add-on, but I don’t think it meets provider expectations
· Brian Behlendorf – Is it possible to have a few different kinds of presence? Such as, I’m contactable only in emergencies or only during office hours?
· Nageshwara Bashyam – You can specify availability and the text can be displayed however you’d like
· Arien Malec – If my default presence is busy, this doesn’t necessarily set an expectation that I can’t use files
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· For client-server communications, XMPP uses TLS encryption based on x509 certificates
· Clients are authenticated to the server using SASL
· Server-server encryption uses TLS. Server-server is authenticated using a SASL external mechanism
· To answer an earlier question from Arien,” does the XMPP approach assume mutual TLS and a single trust model?”: No, XMPP provides a mechanism to use certificates that are independent of each other and not rooted in the same CA. Best practice is to use a common trust anchor.
· Arien Malec – The SASL external mechanism means TLS, right?
· Nageshwara Bashyam – (didn’t catch this)
· Best practice is to use mutual TLS with a routed CA
Questions from Arien Malec
· How does this work in the real XMPP jabber world? How do jabber servers interoperate?
· Nageshwara Bashyam – You use a third party certificate to communicate. However, some people don’t use encryption or certificates. This is not secure.
· Arien Malec – if I’m using gtalk, does it interoperate with other XMPP IM systems?
· Nageshwara Bashyam – We used openfire for the NHIN Direct prototype, which has many applications that can interact with each other and are interoperable
· Arien Malec – If they are interoperable, do they not use a common trust anchor?
· Nageshwara Bashyam – Have not looked at configuration of google talk, but assume that the certificates originate from a common CA
Question from Ravi Madduri
· How does authorization happen?
· Nageshwara Bashyam – Authorization can be implemented in multiple ways
Question from Chris Ferris
· How is end-end trust established? How can you have TLS be the agent for mutual authentication?
· Nageshwara Bashyam – You would have to write some extra software applications to enable additional security measures for signing and encryption of payload
· Chris Ferris – So there would have to be independent security measures applied to the payload?
· Arien Malec – One model allows for trust to be done contractually and another model allows for end-end signing and encryption
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· Client certificates are separate from server certificates
· XMPP uses “to” and “from” to route between HISPs
· Header information as specified is sufficient for routing between HISPs
· It could be a burden for edge clients to extract content manifest data manually
· Wesley Comb’s team has used a HL7-based EMR to interact with a destination
Question from Peter Devault
· How easy is it to add additional metadata to the header?
· Nageshwara Bashyam – Header is restricted by XMPP, but you can add tags for additional metadata
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· Overview of XMPP prototype instantiation and configuration
· Provided demo of XMPP prototype
REST Presentation and Q&A ''– given by Brett Peterson
· Overview of REST
· Why REST?
o It’s simple, ubiquitous, proven, extensible, and scalable
o Integration is fairly simple
o There is a lot of tooling available
o There is a natural x509 certificate directory mechanism
· Still some debate on best way to architect the abstract model’s status function
o Payload is a mail message
· Java-based (Spring MVC) HISP implementation (built by Visionshare, Medplus/Quest)
o Used a REST backbone, but have demonstrated integration with other protocols on edge
o How can we integrate REST to physicians who want to use existing email technology?
o Have demonstrated this SMTP integration with Windows LiveMail email client
o Use S/MIME security to sign and encrypt
o Certificate directory mechanism works well here
· Ruby on Rails HISP implementation(built by Arien Malec)
o REST backbone
o Use S/MIME security to sign and encrypt
o Uses open SSL
o Uses certificate directory mechanism
· Java HISP implementation [built by Argonne National Laboratory (ANL)]
· Provided REST API examples
Comment from Arien Malec
· Right mode for doing this would be to always send the message to the destination HISP address
· This would mean that you’d never have to do three hops, you’d always send the message directly to the destination or their explicit delegate
Continuation of REST Presentation – given by Brett Peterson
· There are options where a doctor can use their existing email client to interoperate with REST
· Due to use of S/MIME, REST approach has built in privacy, authentication, integrity, and non-repudiation.
· Java Spring MVC implementation uses nhin-d-jagent
o Believe that to and from headers should be protected, though this is ultimately a policy choice
· ANL implementation uses SAML
Comment from Christopher Moyer
· We were able to leverage available open source projects for the Java Spring MVC implementation
· Found that S/MIME was easy to use
· Available tooling made it easy to implement the solution
Comment from Arien Malec
· Implementing from the client side is trivial if you don’t have investment in an existing stack
· From the server side, it’s a bit harder than the client, but still fairly trivial
· Building the security agent is relatively easy if you have good mail and certificate handling code to work from
· If we go with the S/MIME approach, we should use really strong, validated code to do extraction, encryption, and signing
Comment from Ravi Madduri
· ANL wanted to use tools developed for NCI’s caBIG for NHIN Direct
· Implemented all NHIN transactions
· Based implementation approach on a real-world scenario demonstrating REST NHIN transactions where a patient could generate a SAML assertion giving permission to a physician to share certain data
o Wanted to have a patient involved in the workflow
o Plan to demonstrate this workflow at Thursday face-to-face
· Made a library for all services
· Were able to use a lot of the security tools that were built for caBIG to do encryption, authorization and certificate issuance
· Were able to create services that used username/password, allowing security to happen in the background
· NHIN Direct security model seems in line with ANL implementation
Questions from Karen Witting
· Had trouble understanding the REST specifications
· How does a source HISP communicate with a destination HISP?
· If I want to get to the certificates, do I have to go to the source HISP?
· Where is the “from” information?
· Brett Peterson – Will begin by answering the certificates question
o The model we’ve worked with is that the certificate distribution mechanism works well when the HISPs themselves are proxying for the certificates
o More challenging if you put key material for a certificate all the way at the source or destination, works better with there is a proxy HISP
· Karen Witting - Assuming that there are trusted intermediaries
· Arien Malec – If you do not trust your HISP for all things, you can still trust the HISP to serve up your public key. This serves as a good publication mechanism. You would still need to sign the certificate yourself with your private key.
· Karen Witting – What would the URI look like for a source HISP-destination HISP transaction?
· Brett Peterson – It would look the same as for a source – source HISP transaction
o How you address your HISP as a source is an orthogonal issue
o The part of the URL that matters, which is the from the nhin portion onward, would be the same
Comment from Arien Malec
· REST allows for role-based security, where the edge role is based on authentication header and the HISP role is based on encrypted payload
· If a POST doesn’t carry an authorization header, but carries an encrypted payload, what you do for processing thereafter depends on the preferences of the two recipients
· You can also plug in your own domain name
· Karen Witting – This is assuming that DNS is properly configured. Are you assuming that DNS is configured differently in different places?
· Arien Malec – Assumption is that the health domain portion of the address should be a special purpose domain
· Karen Witting – The source HISP changes this part
· Arien Malec – This change occurs based on the content container
Question from Karen Witting
· Does the source HISP have access to the entire header?
· Arien Malec – The source HISP has access to the header, not the entire container
· Karen Witting – Then the “to” and “from” must be available?
· Arien Malec – Yes
Question from Nageshwara Bashyam
· How could I prevent the source and destination from accessing the URI?
· Brett Peterson – In a HISP-HISP, server-server transaction, you must decide if you trust the HISP and everything it represents or not
o You can reject a request at the application level. This would be in the S/MIME wrapper and in HISP-HISP TLS.
· Christopher Moyer – We used role-based security, with an edge role and a HISP role, to protect resources appropriately. Also are able to do additional validation at the application layer.
Question from Lin Wan
· How is SAML used for the ANL implementation?
· Ravi Madduri – We created a SAML service that shows a token to the source HISP
o This token shows the subject as the destination HISP, the action as read-only, and also signs the SAML token with the source HISP credential
· Lin Wan – Who uses the assertion?
· Ravi Madduri – Used by the destination HISP. Assertion is generated by the source HISP.
o Not part of the REST specification yet, but wanted to implement a scenario where the patient’s consent could be incorporated in the workflow
o The destination HISP will pull the assertion
· Lin Wan – So this is outside the message transfer use case
· Ravi Madduri – Yes, we wanted to model the patient’s consent
· Lin Wan – Not sure why we’re looking at patient consent since we’re just pushing to the destination
· Brett Peterson – The S/MIME approach gives privacy and also identifies who should access the content
· Lin and Ravi to continue discussing use of SAML assertions for ANL REST implementation offline
Question from Vassil Peytchev
· When you implemented a pop receiver, what did you populate in the email?
· Brett Peterson – The email was populated from the two headers as they were coming in, the content was not altered
· Christopher Moyer – We would expect the email client to hit the pop server as well as the SMTP server
· Vassil Peytchev – But there is no way to ensure any specific configuration
· Brett Peterson – Right, it’s not possible to ensure this
Question from Don Jorgenson
· How do you see access control being realized?
· Ravi Madduri – We made many assumptions about how the SAML is transmitted. Not sure if there is a standard way to do this in the REST world.
IHE Presentation and Q&A ''– given by Peter DeVault
· Overview of the motivations for IHE team
o Many of the participating organizations in the IHE team have already implemented IHE profiles
· Overview of IHE approach
o XDR serves as the backbone for the approach
o Can do XDR end-to-end, but also wanted to demonstrate that edge protocols can vary
· Four demonstration scenarios:
o EMR – EMR
o EMR – Email
o Email – PHR
o Web app – Email
· Have matched each of these demonstration scenarios with corresponding NHIN Direct user stories
· Provided overviews and demonstrations for each of the four scenarios
· Remaining user stories to be addressed by the IHE team:
o Lab- provider
o Provider public health reporting
· Strengths
o Straightforward integration with NHIN Exchange
o Already uses XDR and has common metadata
o One metadata model supports both minimal and extended metadata
o IHE profiles are already developed, enhanced and maintained through an open, formal process
o Can work across a continuum of care settings
· Weaknesses
o Supports point-point encryption, doesn’t support non-trusted intermediaries for end-end encryption
o Can feed this problem into IHE process for a solution
o Intermediaries need to be trusted for many of the NHIN Direct user stories
o IHE approach has intended recipient metadata in the same place as the content container metadata
o ebXML and SOAP can look difficult for developers
§ For ebXML, we will soon have documented examples of how to implement appropriately for each profile
§ For SOAP, no one implements SOAP, it’s already been implemented in a wide range of toolkits
· IHE approach has support from EHR vendors
· IHE approach is mature, small changes may be needed to XDR
· IHE is simple, scalable, and sustainable
· The IHE approach is a set of profiles built on top of SOAP
o A profile is already owned by a sustaining organization
· Note that whatever approach we pick, it needs to be simple from an end user’s point of view, not a developer’s point of view
Question from Arien Malec
· Seems that there are at least two points of centralization with IHE approach:
o Assumption of TLS
o Assumption of UDDI
· Vassil Peytchev – Mutual TLS is no more centralized than any of the other security proposals
o Using UDDI as a routing directory is similar to how DNS operates
o UDDI seems to have similar benefits/drawbacks as any other mechanism
· Arien Malec – If you do mutual TLS for HISP-HISP communication and the server can only serve up one certificate, you are locked into a single rooted trust
· Chris Ferris - Disagree, you do not need a single root to perform mutual authentication for TLS
· Arien Malec – Could the IHE team document how to do mutual TLS without a single rooted trust?
o The IHE specification requires the server to return only one certificate and map this against the client certificate
· Chris Ferris – You may be conflating the nature of what is being authenticated. If you intend to use TLS to authenticate an end user, this would be a concern, but that is not what TLS is intended to do.
· Vassil Peytchev – If you’re asking about HISP-HISP authentication of the server, how is this different than HISP-HISP authentication using REST?
· Brian Behlendorf – Let’s discuss HISP-HISP authentication further during the face-to-face meeting
Question from Arien Malec
· What does the minimal edge spec look like?
· John Moehrke – Difficult to say if you keep changing the requirements
· Could the IHE team re-encode the windows media files into a format that can be more widely used?
· Each of the approaches should document what the minimal edge specification should be
Question from Fred Trotter
· We will have to bridge to NHIN Exchange no matter what the backbone is, because the edge protocols may vary
· Peter DeVault – By doing transforms between XDR and other protocols, we can let edge protocol vary
· Fred Trotter – If you allow for secure email on the edges, will you ever allow secure email point to point?
· Karen Witting – Anyone who wants to implement email can do this
o The way we’re bridging is through XDM
o The minimum receiving capability on the edge is opening a zip. This can be done through many different mechanisms.
o On the sending side, you have to be able to create minimal metadata. A HISP could also create the zip for you.
o If we choose an edge protocol that never creates a zip, it would be difficult to enable interoperability
Question from Fred Trotter
· Do you have to have certain capabilities to send other than generating text for an email?
· Karen Witting – Depends on the choice in metadata. If you want to use email, yes. If you want to use REST, you can use options in the browser, as shown in demonstration four.
· Fred Trotter – You can do the same thing with a SMTP proxy
· Matt Potter – We need to get to what minimum metadata is. Metadata becomes less useful as you step down toward the minimum.
Question from Nathan Hogge
· How will a message be delivered using XDR from the HISP to the destination?
· Vassil Peytchev – Assuming that the destination-HISP protocol is XDR, then the delivery is similar to the HISP–HISP transaction
Question from Arien Malec
· How would you address the requirement to support a practice that cannot open a port?
· Vassil Peytchev – A non-XDR edge protocol would be used
· Karen Witting – This is a case of translating XDR to XDM and sending the zip file in one of many ways
SMTP Presentation and Q&A ''– given by Sean Nolan
· Believe that the concepts behind email match the charter of NHIN Direct
· SMTP implementations also match charter, with the exception of privacy & security
o Implementation is just email
o Security agent is plugged in at any point in the pipeline, from the creation of the message at the client to the source HISP
o Channels can be encrypted using TLS to protect routing data
· Structure and opportunities for innovation
o Scalable structure (can support text, unstructured attachments, structured attachments, metadata MIME part)
o Transport is well tested, can innovate in the payload
· Security agent
o Scalable approach to PKI management
o Certificate management can be handled by user desktop, organization, or HISP
o Ability to use SMTP across implementations shows transport-independence
o S/MIME doesn’t speak to which headers should be used, we will need to address this if SMTP is chosen
· Reliable messaging will likely become a requirement, SMTP support this
· Use of existing technologies is important due to operations, security history, multi-tenant issues already being worked out, industry/training skill set, and account support for SMTP
· SMTP demonstration technologies
o Cerner millennium
o Microsoft HealthVault
o Java-based and Windows-based email clients
o DNS
Demonstration from Andy Heeren, Sean Nolan, and Umesh Madan
· Note the ease of integration using a standard email client, integration with a EHR, and connection to a PHR
· HISPs shown are Microsoft for the sender and Cerner for the receiver
· Provided a walkthrough of SMTP demonstration
Comment from Andy Heeren
· Will post SMTP demonstration and additional accompanying information to the wiki
Comment from Arien Malec
· Semantics of a Return Receipt are consistent with NHIN Direct requirements
o NHIN Direct requires that notification of receipt is sent, but there is no requirement for confirmation that message has been read/approved
· How do you manage multi-hops?
· Sean Nolan – This is controllable at the SMTP server level and at the firewall level
o However, this doesn’t really matter
o May want to document best practices for configuration.
· Arien Malec – You may be exposing to/from information
· Sean Nolan – If protecting this information is required, you can use SSL and configure policies to enforce SSL. In normal options this isn’t a challenge, but could be a DNS spoofing scenario
Question' from Arien Malec
· How do you integrate SMTP into HISP workflows and EHR workflows?
· Sean Nolan – For EHRs: On an inbound basis, many/most EHRs address the concept of a doctor’s email inbox already.
o If the concept is not an EHR, you would need to add this or have a secondary message application. This would be true whether you were using SMTP or not.
o For HISP: This is about data center operations, you would have a bit of work to do on managing records
· Arien Malec – You would either need to build SMTP semantics into the workflow or interface with the messagebox format
· Sean Nolan – You would have to do something new, but this would be incremental on top of existing email integration.
o The capability worksheet for SMTP addresses ways this could be done
o Don’t think we are setting up data centers for attack
o We’ll create the embed agent we’re using for the reference implementation for a number of different servers
o Reference model implementations can use existing SMTP servers as a proxy
Question from Vassil Peytchev
· Is there a standard way to set up control of an email client?
· Sean Nolan – This is widely done across many industries already. Could be done either at organization level or HISP level for healthcare.
· Arien Malec – Isn’t Vassil’s question more that an email client can only send/receive from a trusted source?
· Sean Nolan – The trust model does this for you. If an address doesn’t have a trusted certificate, the message will be rejected
o This is already done today.
o You would use DNS to federate the distribution of certificates to ensure that you only send messages to addresses you want to send to and only receive messages from trusted anchors
· Vassil Peytchev – You are building additional infrastructure then
· Sean Nolan – Yes, you need to build the agent
· Fred Trotter – This agent would not just be email
· Sean Nolan – It’s S/MIME. The change is to implement a piece of code that can be used at different places in the mail pipeline
· Arien Malec – This works as a filter in the mail pipeline
Question from Eric Heflin
· What happens when a certificate expires?
· Sean Nolan – If you are using S/MIME in the client, we haven’t solved this problem
o In the model where the agent is part of the process, the message is turned into a clear-text representation so that the final client doesn’t have to refresh
o Because of the DNS distribution of public certificates, the agent can refresh any certificates that are not anchors. Anchors would have to be managed manually, but any child certificate could be refreshed automatically.
Question from Christopher Ferris
· You have an agent that must be inserted into the chain, is it inserted once or in multiple places?
· Sean Nolan – Once per endpoint
· Chris Ferris – On both the sending and receiving sides?
· Sean Nolan – Yes
· Arien Malec – Minimal use is just at send and just at receive. (didn’t catch maximal use)
· Chris Ferris – Client would need to be specially configured to talk just to the HISP
· Sean Nolan – The NHIN Direct address is an account that is “agentified”
· Arien Malec – You couldn’t use your standard yahoo email account to do this
· Sean Nolan – Actually, a normal web-based email, like hotmail or gmail, can does this through a desktop agent
· Arien Malec – Then you would either need to take on the challenge of PKI locally or use a special email account
· Sean Nolan – Taking on the PKI challenge can mean 1) traditional S/MIME, which is challenging, or 2) anchor management, where you need to refresh a small set of certificates that speak to organizational relationships
Question from Christopher Ferris
· If I have a certificate from an organization and I am removed from that organization, what happens?
· Sean Nolan – You would use certificate revocation. There also could be policies around this, such as short-term certificate expiration.
Comment from David Kibbe
· An enormous amount of work has been done in a short amount of time by all of the teams.
· There are problems with each one of these technologies, but there is a lot of enthusiasm from each team to work through these last details
· Seems that the most important, innovative result is not the particular protocols, but the concept of a nimble HISP/the role of a HISP
· Cannot imagine a HISP being successful without XMPP 2-3 years from now. As a secure protocol for EHR-EHR, REST seems like a good choice. But for 80% of physicians in the near-time, the only always-on applications are email clients and web browsers. Many physicians do not have EHRs.
· I expect that the first wave will demand out-of-the-box solutions that work with email clients and web-based email applications
· We should consider not requiring additional vendor product development, but not impeding development either
· We need to decide where to start, and it should be with something that can be implemented quickly and sold to the doctors for stage 1 MU.
Comment from Ravi Madduri
· If you have a lot of images that need to be sent, would they be sent via SMTP?
· Sean Nolan – Would not expect that large amounts of images would be sent over email. Expect that another protocol would be needed for this.
Comment from Lin Wan
· The agent will be the central point to manage security and certificates. Have you built a UI for this?
· Sean Nolan – We have not built a UI for this. This is the next thing to build out, but that is likely true for all approaches.
Comment from Vassil Peytchev
· There is a good possibility that a recipient could participate in direct exchange under different roles, would they use the same NHIN Direct address for these? Different roles may have different HISPs, different healthcare domains, etc.
· Sean Nolan – Originally, NHIN Direct decided that we would not seek to know about multiple endpoints.
o But, people with multiple endpoints shouldn’t pose a challenge. Clients allow for aggregation.
o For multiple trust circles, this is where different anchors come into play. Could have different anchors for different purposes. This is part of agent negotiation
· Vassil Peytchev – If there is one user and multiple HISPs, do you need to have different email addresses?
· Sean Nolan – Yes
o Many email clients support sub-addressing, which you could use for separated routing of roles
· Arien Malec – This is common among REST, SMTP, and XMPP
Question from Arien Malec
· How can you get to an endpoint level from a certificate entry?
· Sean Nolan – (didn’t catch this)
Question from David Kibbe
· Almost all other approaches showed SMTP email interaction
· Given this, it seems that end user experience would not be very different across all approaches
· How does SMTP approach differentiate from these?
· Sean Nolan – There are some special features to SMTP that would only be supported if SMTP served as backbone
o Operation of servers and the cost of SMTP will be major factor in adoption of NHIN Direct by ISPs
o SMTP will require minimal additional coding and work
· David Kibbe – This gets to who can become a HISP
· Sean Nolan – The entire industry of ISPs would have a small additional burden to become a HISP. By using SMTP, we would see dramatically different uptake of the NHIN Direct solution
Question from Christopher Ferris
· If you’re using unencrypted email with just SSL between the two, isn’t this a security risk?
· Sean Nolan – Every single approach is vulnerable to attack on the desktop. SMTP does not have special protection.
· Arien Malec – Antivirus filtering could be a good value-add for SMTP
Question from John Moehrke
· In order to achieve MU, there is more involved than just sending messages.
· How does this type of transport integrate with an application that is doing the grunt work of MU (creating a referral, lab results, etc)?
· How do you separate what email clients can do vs a SMTP API?
· Sean Nolan – We may have blurred some of this during the presentation
o Many people could use a full featured email client as well as an EHR with SMTP tools to integrate
Time: 11am-1pm and 2pm-4pm EST
Attendees: Jackie Key, George Cole, Steven Waldren, Ravi Madduri, Didi Davis, David McCallie, Greg Meyer, David Kibbe, Janet Campbell, Vassil Peytchev, Peter DeVault, Matt Potter, Nageshwara Bashyam, Noam H. Arzt, Karen Witting, Don Jorgenson, Matt Koehler, Parag More, Vince Lewis, Eric Heflin, Mark Stine, Umesh Madan, Sean Nolan, Arien Malec, Brian Behlendorf, Dan Kazzaz, Martin Prahl, Chris Lomonico, Brett Peterson, Fred Trotter, Nathan Hogge, George Komatsoulis, Christopher Moyer, Lin Wan, John Moehrke
Actions for this Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 29 |
6/8/10 |
Post presentation materials for each approach to wiki in a widely usable format |
Open |
Concrete Implementation Teams |
6/10/10 |
| 30 |
6/8/10 |
Document the minimal edge specification for each approach |
Open |
Concrete Implementation Teams |
6/10/10 |
| 31 |
6/8/10 |
Continue to discuss use of SAML assertions by ANL REST implementation on wiki |
Open |
Lin Wan/Ravi Madduri |
6/10/10 |
| 32 |
6/8/10 |
Further discuss HISP-HISP authentication during the face-to-face meeting |
Open |
Implementation Group |
6/11/10 |
Actions from last Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 26 |
6/1/10 |
Add optional S&T risk analysis section to capability worksheet |
Open |
Sean Nolan |
6/2/10 |
| 27 |
6/1/10 |
Provide HITSC reviewers with draft capability worksheets and pointers to relevant specifications/documents |
Closed |
Arien |
6/2/10 |
| 28 |
6/1/10 |
Schedule hour-long review meetings for the HITSC review team on June 7th and 9th |
Closed |
Arien |
6/4/10 |
Agenda
- Presentation and discussion of each team's proposal. ~1 hour each
Live Meeting Link:
[1]
Note: we really want every team to hear every other team's presentation, and ask questions & give feedback, and be a part of the consensus decision, because ultimately we are one team and will be working on a single implementation. For that reason, we are not posting the schedule of presentations in advance.
Presentation Materials:
XMPP Presentation from 6/8/2010 Extended Session:
REST Presentation from 6/8/2010 Extended Session:
SMTP Presentation from 6/8/2010 Extended Session:
IHE Presentation from 6/8/2010 Extended Session:
Notes
Comment from Brian Behlendorf
· Goal is not come up with a single proposal, but to come together as one team as agree upon one or more options to move forward with
· Overview of “Rules of the Road” for today’s presentations
· Each team will have an hour to present and take questions
Comment from Arien Malec
· Let’s speak openly and honestly, but without rancor
XMPP Presentation and Q&A ''– given by Nageshwara Bashyam
· XMPP meets the goals of the NHIN Direct project, providing simple, direct, secure, and scalable transport
· XMPP can support features beyond basic NHIN Direct functions to support the creation of innovative healthcare applications
Question from Arien Malec
· To what extent can these innovative features be disabled if they’re not needed or desired?
· Nageshwara Bashyam – You can configure certain features as needed, but some features cannot be turned off.
Question from Ravi Madduri
· Through experience, I have found it hard in a hospital environment to get ports open. XMPP seems to require open ports. Do you see any difficulties with this?
· Nageshwara Bashyam - For client to server communication, you can use HTTP binding. Not sure if you can use a HTTP port for server-server.
o Not every vendor can support these functions
Question from David Kibbe
· As a physician I’m excited about having instant messaging available
· Struck that when you define simplicity, you define this from a developer’s perspective and not a end user’s perspective. Simplicity should be defined from the end user’s point of view. How would XMPP allow for this?
· Nageshwara Bashyam – You can use java libraries and integrate with an email client
· David Kibbe – If we’re depending on developers to develop the clients for the physicians and their patients, then we’re talking about something in the future.
o In the present, we need to talk about using existing web-based email clients where the physician will not need to acquire additional technology. We shouldn’t put a burden on end users beyond what they currently have in their offices.
o Development responsibility here is on the EHR vendors. This is exciting, but will happen in future if the first level is successful
· Nageshwara Bashyam – XMPP is not as prevalent in the industry as some other mechanisms.
· Brian Behlendorf – Note that there are web-based XMPP clients
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· XMPP uses address that are similar to email addresses
Questions from Arien Malec
· Are you assuming mutual TLS? Does that assume a single trust model?
· Nageshwara Bashyam – Will address security in the next slides
· Arien Malec – If you don't send presence stanzas, does out of band file transfer work anyway?
· Nageshwara Bashyam – Typically the communication allows the client to keep retrying
· Arien Malec – Presence is a nice add-on, but I don’t think it meets provider expectations
· Brian Behlendorf – Is it possible to have a few different kinds of presence? Such as, I’m contactable only in emergencies or only during office hours?
· Nageshwara Bashyam – You can specify availability and the text can be displayed however you’d like
· Arien Malec – If my default presence is busy, this doesn’t necessarily set an expectation that I can’t use files
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· For client-server communications, XMPP uses TLS encryption based on x509 certificates
· Clients are authenticated to the server using SASL
· Server-server encryption uses TLS. Server-server is authenticated using a SASL external mechanism
· To answer an earlier question from Arien,” does the XMPP approach assume mutual TLS and a single trust model?”: No, XMPP provides a mechanism to use certificates that are independent of each other and not rooted in the same CA. Best practice is to use a common trust anchor.
· Arien Malec – The SASL external mechanism means TLS, right?
· Nageshwara Bashyam – (didn’t catch this)
· Best practice is to use mutual TLS with a routed CA
Questions from Arien Malec
· How does this work in the real XMPP jabber world? How do jabber servers interoperate?
· Nageshwara Bashyam – You use a third party certificate to communicate. However, some people don’t use encryption or certificates. This is not secure.
· Arien Malec – if I’m using gtalk, does it interoperate with other XMPP IM systems?
· Nageshwara Bashyam – We used openfire for the NHIN Direct prototype, which has many applications that can interact with each other and are interoperable
· Arien Malec – If they are interoperable, do they not use a common trust anchor?
· Nageshwara Bashyam – Have not looked at configuration of google talk, but assume that the certificates originate from a common CA
Question from Ravi Madduri
· How does authorization happen?
· Nageshwara Bashyam – Authorization can be implemented in multiple ways
Question from Chris Ferris
· How is end-end trust established? How can you have TLS be the agent for mutual authentication?
· Nageshwara Bashyam – You would have to write some extra software applications to enable additional security measures for signing and encryption of payload
· Chris Ferris – So there would have to be independent security measures applied to the payload?
· Arien Malec – One model allows for trust to be done contractually and another model allows for end-end signing and encryption
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· Client certificates are separate from server certificates
· XMPP uses “to” and “from” to route between HISPs
· Header information as specified is sufficient for routing between HISPs
· It could be a burden for edge clients to extract content manifest data manually
· Wesley Comb’s team has used a HL7-based EMR to interact with a destination
Question from Peter Devault
· How easy is it to add additional metadata to the header?
· Nageshwara Bashyam – Header is restricted by XMPP, but you can add tags for additional metadata
Continuation of XMPP Presentation – given by Nageshwara Bashyam
· Overview of XMPP prototype instantiation and configuration
· Provided demo of XMPP prototype
REST Presentation and Q&A ''– given by Brett Peterson
· Overview of REST
· Why REST?
o It’s simple, ubiquitous, proven, extensible, and scalable
o Integration is fairly simple
o There is a lot of tooling available
o There is a natural x509 certificate directory mechanism
· Still some debate on best way to architect the abstract model’s status function
o Payload is a mail message
· Java-based (Spring MVC) HISP implementation (built by Visionshare, Medplus/Quest)
o Used a REST backbone, but have demonstrated integration with other protocols on edge
o How can we integrate REST to physicians who want to use existing email technology?
o Have demonstrated this SMTP integration with Windows LiveMail email client
o Use S/MIME security to sign and encrypt
o Certificate directory mechanism works well here
· Ruby on Rails HISP implementation(built by Arien Malec)
o REST backbone
o Use S/MIME security to sign and encrypt
o Uses open SSL
o Uses certificate directory mechanism
· Java HISP implementation [built by Argonne National Laboratory (ANL)]
· Provided REST API examples
Comment from Arien Malec
· Right mode for doing this would be to always send the message to the destination HISP address
· This would mean that you’d never have to do three hops, you’d always send the message directly to the destination or their explicit delegate
Continuation of REST Presentation – given by Brett Peterson
· There are options where a doctor can use their existing email client to interoperate with REST
· Due to use of S/MIME, REST approach has built in privacy, authentication, integrity, and non-repudiation.
· Java Spring MVC implementation uses nhin-d-jagent
o Believe that to and from headers should be protected, though this is ultimately a policy choice
· ANL implementation uses SAML
Comment from Christopher Moyer
· We were able to leverage available open source projects for the Java Spring MVC implementation
· Found that S/MIME was easy to use
· Available tooling made it easy to implement the solution
Comment from Arien Malec
· Implementing from the client side is trivial if you don’t have investment in an existing stack
· From the server side, it’s a bit harder than the client, but still fairly trivial
· Building the security agent is relatively easy if you have good mail and certificate handling code to work from
· If we go with the S/MIME approach, we should use really strong, validated code to do extraction, encryption, and signing
Comment from Ravi Madduri
· ANL wanted to use tools developed for NCI’s caBIG for NHIN Direct
· Implemented all NHIN transactions
· Based implementation approach on a real-world scenario demonstrating REST NHIN transactions where a patient could generate a SAML assertion giving permission to a physician to share certain data
o Wanted to have a patient involved in the workflow
o Plan to demonstrate this workflow at Thursday face-to-face
· Made a library for all services
· Were able to use a lot of the security tools that were built for caBIG to do encryption, authorization and certificate issuance
· Were able to create services that used username/password, allowing security to happen in the background
· NHIN Direct security model seems in line with ANL implementation
Questions from Karen Witting
· Had trouble understanding the REST specifications
· How does a source HISP communicate with a destination HISP?
· If I want to get to the certificates, do I have to go to the source HISP?
· Where is the “from” information?
· Brett Peterson – Will begin by answering the certificates question
o The model we’ve worked with is that the certificate distribution mechanism works well when the HISPs themselves are proxying for the certificates
o More challenging if you put key material for a certificate all the way at the source or destination, works better with there is a proxy HISP
· Karen Witting - Assuming that there are trusted intermediaries
· Arien Malec – If you do not trust your HISP for all things, you can still trust the HISP to serve up your public key. This serves as a good publication mechanism. You would still need to sign the certificate yourself with your private key.
· Karen Witting – What would the URI look like for a source HISP-destination HISP transaction?
· Brett Peterson – It would look the same as for a source – source HISP transaction
o How you address your HISP as a source is an orthogonal issue
o The part of the URL that matters, which is the from the nhin portion onward, would be the same
Comment from Arien Malec
· REST allows for role-based security, where the edge role is based on authentication header and the HISP role is based on encrypted payload
· If a POST doesn’t carry an authorization header, but carries an encrypted payload, what you do for processing thereafter depends on the preferences of the two recipients
· You can also plug in your own domain name
· Karen Witting – This is assuming that DNS is properly configured. Are you assuming that DNS is configured differently in different places?
· Arien Malec – Assumption is that the health domain portion of the address should be a special purpose domain
· Karen Witting – The source HISP changes this part
· Arien Malec – This change occurs based on the content container
Question from Karen Witting
· Does the source HISP have access to the entire header?
· Arien Malec – The source HISP has access to the header, not the entire container
· Karen Witting – Then the “to” and “from” must be available?
· Arien Malec – Yes
Question from Nageshwara Bashyam
· How could I prevent the source and destination from accessing the URI?
· Brett Peterson – In a HISP-HISP, server-server transaction, you must decide if you trust the HISP and everything it represents or not
o You can reject a request at the application level. This would be in the S/MIME wrapper and in HISP-HISP TLS.
· Christopher Moyer – We used role-based security, with an edge role and a HISP role, to protect resources appropriately. Also are able to do additional validation at the application layer.
Question from Lin Wan
· How is SAML used for the ANL implementation?
· Ravi Madduri – We created a SAML service that shows a token to the source HISP
o This token shows the subject as the destination HISP, the action as read-only, and also signs the SAML token with the source HISP credential
· Lin Wan – Who uses the assertion?
· Ravi Madduri – Used by the destination HISP. Assertion is generated by the source HISP.
o Not part of the REST specification yet, but wanted to implement a scenario where the patient’s consent could be incorporated in the workflow
o The destination HISP will pull the assertion
· Lin Wan – So this is outside the message transfer use case
· Ravi Madduri – Yes, we wanted to model the patient’s consent
· Lin Wan – Not sure why we’re looking at patient consent since we’re just pushing to the destination
· Brett Peterson – The S/MIME approach gives privacy and also identifies who should access the content
· Lin and Ravi to continue discussing use of SAML assertions for ANL REST implementation offline
Question from Vassil Peytchev
· When you implemented a pop receiver, what did you populate in the email?
· Brett Peterson – The email was populated from the two headers as they were coming in, the content was not altered
· Christopher Moyer – We would expect the email client to hit the pop server as well as the SMTP server
· Vassil Peytchev – But there is no way to ensure any specific configuration
· Brett Peterson – Right, it’s not possible to ensure this
Question from Don Jorgenson
· How do you see access control being realized?
· Ravi Madduri – We made many assumptions about how the SAML is transmitted. Not sure if there is a standard way to do this in the REST world.
IHE Presentation and Q&A ''– given by Peter DeVault
· Overview of the motivations for IHE team
o Many of the participating organizations in the IHE team have already implemented IHE profiles
· Overview of IHE approach
o XDR serves as the backbone for the approach
o Can do XDR end-to-end, but also wanted to demonstrate that edge protocols can vary
· Four demonstration scenarios:
o EMR – EMR
o EMR – Email
o Email – PHR
o Web app – Email
· Have matched each of these demonstration scenarios with corresponding NHIN Direct user stories
· Provided overviews and demonstrations for each of the four scenarios
· Remaining user stories to be addressed by the IHE team:
o Lab- provider
o Provider public health reporting
· Strengths
o Straightforward integration with NHIN Exchange
o Already uses XDR and has common metadata
o One metadata model supports both minimal and extended metadata
o IHE profiles are already developed, enhanced and maintained through an open, formal process
o Can work across a continuum of care settings
· Weaknesses
o Supports point-point encryption, doesn’t support non-trusted intermediaries for end-end encryption
o Can feed this problem into IHE process for a solution
o Intermediaries need to be trusted for many of the NHIN Direct user stories
o IHE approach has intended recipient metadata in the same place as the content container metadata
o ebXML and SOAP can look difficult for developers
§ For ebXML, we will soon have documented examples of how to implement appropriately for each profile
§ For SOAP, no one implements SOAP, it’s already been implemented in a wide range of toolkits
· IHE approach has support from EHR vendors
· IHE approach is mature, small changes may be needed to XDR
· IHE is simple, scalable, and sustainable
· The IHE approach is a set of profiles built on top of SOAP
o A profile is already owned by a sustaining organization
· Note that whatever approach we pick, it needs to be simple from an end user’s point of view, not a developer’s point of view
Question from Arien Malec
· Seems that there are at least two points of centralization with IHE approach:
o Assumption of TLS
o Assumption of UDDI
· Vassil Peytchev – Mutual TLS is no more centralized than any of the other security proposals
o Using UDDI as a routing directory is similar to how DNS operates
o UDDI seems to have similar benefits/drawbacks as any other mechanism
· Arien Malec – If you do mutual TLS for HISP-HISP communication and the server can only serve up one certificate, you are locked into a single rooted trust
· Chris Ferris - Disagree, you do not need a single root to perform mutual authentication for TLS
· Arien Malec – Could the IHE team document how to do mutual TLS without a single rooted trust?
o The IHE specification requires the server to return only one certificate and map this against the client certificate
· Chris Ferris – You may be conflating the nature of what is being authenticated. If you intend to use TLS to authenticate an end user, this would be a concern, but that is not what TLS is intended to do.
· Vassil Peytchev – If you’re asking about HISP-HISP authentication of the server, how is this different than HISP-HISP authentication using REST?
· Brian Behlendorf – Let’s discuss HISP-HISP authentication further during the face-to-face meeting
Question from Arien Malec
· What does the minimal edge spec look like?
· John Moehrke – Difficult to say if you keep changing the requirements
· Could the IHE team re-encode the windows media files into a format that can be more widely used?
· Each of the approaches should document what the minimal edge specification should be
Question from Fred Trotter
· We will have to bridge to NHIN Exchange no matter what the backbone is, because the edge protocols may vary
· Peter DeVault – By doing transforms between XDR and other protocols, we can let edge protocol vary
· Fred Trotter – If you allow for secure email on the edges, will you ever allow secure email point to point?
· Karen Witting – Anyone who wants to implement email can do this
o The way we’re bridging is through XDM
o The minimum receiving capability on the edge is opening a zip. This can be done through many different mechanisms.
o On the sending side, you have to be able to create minimal metadata. A HISP could also create the zip for you.
o If we choose an edge protocol that never creates a zip, it would be difficult to enable interoperability
Question from Fred Trotter
· Do you have to have certain capabilities to send other than generating text for an email?
· Karen Witting – Depends on the choice in metadata. If you want to use email, yes. If you want to use REST, you can use options in the browser, as shown in demonstration four.
· Fred Trotter – You can do the same thing with a SMTP proxy
· Matt Potter – We need to get to what minimum metadata is. Metadata becomes less useful as you step down toward the minimum.
Question from Nathan Hogge
· How will a message be delivered using XDR from the HISP to the destination?
· Vassil Peytchev – Assuming that the destination-HISP protocol is XDR, then the delivery is similar to the HISP–HISP transaction
Question from Arien Malec
· How would you address the requirement to support a practice that cannot open a port?
· Vassil Peytchev – A non-XDR edge protocol would be used
· Karen Witting – This is a case of translating XDR to XDM and sending the zip file in one of many ways
SMTP Presentation and Q&A ''– given by Sean Nolan
· Believe that the concepts behind email match the charter of NHIN Direct
· SMTP implementations also match charter, with the exception of privacy & security
o Implementation is just email
o Security agent is plugged in at any point in the pipeline, from the creation of the message at the client to the source HISP
o Channels can be encrypted using TLS to protect routing data
· Structure and opportunities for innovation
o Scalable structure (can support text, unstructured attachments, structured attachments, metadata MIME part)
o Transport is well tested, can innovate in the payload
· Security agent
o Scalable approach to PKI management
o Certificate management can be handled by user desktop, organization, or HISP
o Ability to use SMTP across implementations shows transport-independence
o S/MIME doesn’t speak to which headers should be used, we will need to address this if SMTP is chosen
· Reliable messaging will likely become a requirement, SMTP support this
· Use of existing technologies is important due to operations, security history, multi-tenant issues already being worked out, industry/training skill set, and account support for SMTP
· SMTP demonstration technologies
o Cerner millennium
o Microsoft HealthVault
o Java-based and Windows-based email clients
o DNS
Demonstration from Andy Heeren, Sean Nolan, and Umesh Madan
· Note the ease of integration using a standard email client, integration with a EHR, and connection to a PHR
· HISPs shown are Microsoft for the sender and Cerner for the receiver
· Provided a walkthrough of SMTP demonstration
Comment from Andy Heeren
· Will post SMTP demonstration and additional accompanying information to the wiki
Comment from Arien Malec
· Semantics of a Return Receipt are consistent with NHIN Direct requirements
o NHIN Direct requires that notification of receipt is sent, but there is no requirement for confirmation that message has been read/approved
· How do you manage multi-hops?
· Sean Nolan – This is controllable at the SMTP server level and at the firewall level
o However, this doesn’t really matter
o May want to document best practices for configuration.
· Arien Malec – You may be exposing to/from information
· Sean Nolan – If protecting this information is required, you can use SSL and configure policies to enforce SSL. In normal options this isn’t a challenge, but could be a DNS spoofing scenario
Question' from Arien Malec
· How do you integrate SMTP into HISP workflows and EHR workflows?
· Sean Nolan – For EHRs: On an inbound basis, many/most EHRs address the concept of a doctor’s email inbox already.
o If the concept is not an EHR, you would need to add this or have a secondary message application. This would be true whether you were using SMTP or not.
o For HISP: This is about data center operations, you would have a bit of work to do on managing records
· Arien Malec – You would either need to build SMTP semantics into the workflow or interface with the messagebox format
· Sean Nolan – You would have to do something new, but this would be incremental on top of existing email integration.
o The capability worksheet for SMTP addresses ways this could be done
o Don’t think we are setting up data centers for attack
o We’ll create the embed agent we’re using for the reference implementation for a number of different servers
o Reference model implementations can use existing SMTP servers as a proxy
Question from Vassil Peytchev
· Is there a standard way to set up control of an email client?
· Sean Nolan – This is widely done across many industries already. Could be done either at organization level or HISP level for healthcare.
· Arien Malec – Isn’t Vassil’s question more that an email client can only send/receive from a trusted source?
· Sean Nolan – The trust model does this for you. If an address doesn’t have a trusted certificate, the message will be rejected
o This is already done today.
o You would use DNS to federate the distribution of certificates to ensure that you only send messages to addresses you want to send to and only receive messages from trusted anchors
· Vassil Peytchev – You are building additional infrastructure then
· Sean Nolan – Yes, you need to build the agent
· Fred Trotter – This agent would not just be email
· Sean Nolan – It’s S/MIME. The change is to implement a piece of code that can be used at different places in the mail pipeline
· Arien Malec – This works as a filter in the mail pipeline
Question from Eric Heflin
· What happens when a certificate expires?
· Sean Nolan – If you are using S/MIME in the client, we haven’t solved this problem
o In the model where the agent is part of the process, the message is turned into a clear-text representation so that the final client doesn’t have to refresh
o Because of the DNS distribution of public certificates, the agent can refresh any certificates that are not anchors. Anchors would have to be managed manually, but any child certificate could be refreshed automatically.
Question from Christopher Ferris
· You have an agent that must be inserted into the chain, is it inserted once or in multiple places?
· Sean Nolan – Once per endpoint
· Chris Ferris – On both the sending and receiving sides?
· Sean Nolan – Yes
· Arien Malec – Minimal use is just at send and just at receive. (didn’t catch maximal use)
· Chris Ferris – Client would need to be specially configured to talk just to the HISP
· Sean Nolan – The NHIN Direct address is an account that is “agentified”
· Arien Malec – You couldn’t use your standard yahoo email account to do this
· Sean Nolan – Actually, a normal web-based email, like hotmail or gmail, can does this through a desktop agent
· Arien Malec – Then you would either need to take on the challenge of PKI locally or use a special email account
· Sean Nolan – Taking on the PKI challenge can mean 1) traditional S/MIME, which is challenging, or 2) anchor management, where you need to refresh a small set of certificates that speak to organizational relationships
Question from Christopher Ferris
· If I have a certificate from an organization and I am removed from that organization, what happens?
· Sean Nolan – You would use certificate revocation. There also could be policies around this, such as short-term certificate expiration.
Comment from David Kibbe
· An enormous amount of work has been done in a short amount of time by all of the teams.
· There are problems with each one of these technologies, but there is a lot of enthusiasm from each team to work through these last details
· Seems that the most important, innovative result is not the particular protocols, but the concept of a nimble HISP/the role of a HISP
· Cannot imagine a HISP being successful without XMPP 2-3 years from now. As a secure protocol for EHR-EHR, REST seems like a good choice. But for 80% of physicians in the near-time, the only always-on applications are email clients and web browsers. Many physicians do not have EHRs.
· I expect that the first wave will demand out-of-the-box solutions that work with email clients and web-based email applications
· We should consider not requiring additional vendor product development, but not impeding development either
· We need to decide where to start, and it should be with something that can be implemented quickly and sold to the doctors for stage 1 MU.
Comment from Ravi Madduri
· If you have a lot of images that need to be sent, would they be sent via SMTP?
· Sean Nolan – Would not expect that large amounts of images would be sent over email. Expect that another protocol would be needed for this.
Comment from Lin Wan
· The agent will be the central point to manage security and certificates. Have you built a UI for this?
· Sean Nolan – We have not built a UI for this. This is the next thing to build out, but that is likely true for all approaches.
Comment from Vassil Peytchev
· There is a good possibility that a recipient could participate in direct exchange under different roles, would they use the same NHIN Direct address for these? Different roles may have different HISPs, different healthcare domains, etc.
· Sean Nolan – Originally, NHIN Direct decided that we would not seek to know about multiple endpoints.
o But, people with multiple endpoints shouldn’t pose a challenge. Clients allow for aggregation.
o For multiple trust circles, this is where different anchors come into play. Could have different anchors for different purposes. This is part of agent negotiation
· Vassil Peytchev – If there is one user and multiple HISPs, do you need to have different email addresses?
· Sean Nolan – Yes
o Many email clients support sub-addressing, which you could use for separated routing of roles
· Arien Malec – This is common among REST, SMTP, and XMPP
Question from Arien Malec
· How can you get to an endpoint level from a certificate entry?
· Sean Nolan – (didn’t catch this)
Question from David Kibbe
· Almost all other approaches showed SMTP email interaction
· Given this, it seems that end user experience would not be very different across all approaches
· How does SMTP approach differentiate from these?
· Sean Nolan – There are some special features to SMTP that would only be supported if SMTP served as backbone
o Operation of servers and the cost of SMTP will be major factor in adoption of NHIN Direct by ISPs
o SMTP will require minimal additional coding and work
· David Kibbe – This gets to who can become a HISP
· Sean Nolan – The entire industry of ISPs would have a small additional burden to become a HISP. By using SMTP, we would see dramatically different uptake of the NHIN Direct solution
Question from Christopher Ferris
· If you’re using unencrypted email with just SSL between the two, isn’t this a security risk?
· Sean Nolan – Every single approach is vulnerable to attack on the desktop. SMTP does not have special protection.
· Arien Malec – Antivirus filtering could be a good value-add for SMTP
Question from John Moehrke
· In order to achieve MU, there is more involved than just sending messages.
· How does this type of transport integrate with an application that is doing the grunt work of MU (creating a referral, lab results, etc)?
· How do you separate what email clients can do vs a SMTP API?
· Sean Nolan – We may have blurred some of this during the presentation
o Many people could use a full featured email client as well as an EHR with SMTP tools to integrate