Implementation Group Meeting 06102010

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 10, 2010
Time: 3pm-6pm
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 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

Actions from last week
n/a
Welcome and Agenda Overview from Arien Malec

Introduction from Claudia Williams:

• Meaningful use (MU)
  • Trajectory of MU hinges on information sharing between providers
  • Phase I articulates specific ways for this information sharing to occur
  • To achieve MU phase I, we must hold to the following:
    • Be focused and concrete
    • Be realistic, if we get the right tools in place
    • Need to move rapidly
• NHIN
  • Our conception of NHIN can support rapid progress
  • NHIN must realistically support providers where they are today and also move toward more robust information sharing over time
• Principles
  • Need to work backward from the desired outcome to come up with technology
  • NHIN Direct must be:
    • Bold and incremental
    • Reality based, working from where we are today to get where we need to be
    • Action-oriented
    • Foundational but scalable
    • Open to all
    • Ensure public trust and promote transparency, hinging technology choices on policy practices
    • Evidence based, real-world implementation
• Work today
  • We have a huge opportunity to make rapid progress, our work today is very important
  • Cannot let perfect get in the way of good progress, even if it’s not exactly what you may have in mind
  • Simple innovation to support the little guy and move toward more robust capabilities

Introduction from Arien Malec:

• The work we’re doing is in the national interest and will benefit the health and healthcare of all the citizens of this country
  • Our core value is to ensure that our decisions are made with the national interest at the forefront of our minds
• Our decisions must pass policy muster, must be able to scale, and must be able to meet needs of providers
• Our goal is to agree on a path forward and to acknowledge that even if that path is not your preferred choice, that it is at least a good path

• Review of timeline
• Review of key deliverables
  • Most important of these deliverables are the specifications for our chosen path forward
• Overview of consensus process
  • Our final decision may not necessarily be the best decision, but the decision with the fewest bugs. We should view any objections or obstacles as bugs to be fixed
  • Everyone should be prepared to state why they may have objections to a particular approach
• Overview of rules of the road

Concrete Implementation Team Presentations:

Overview of SMTP – provided by Sean Nolan

• SMTP is really about the email backbone
• Perceive the NHIN Direct charter as aligning very closely with email
• Developed a security agent, based on S/MIME, which can be plugged in at any point in the pipeline between the source and the source HISP
• SMTP has the ability to secure routing data, if required by policy
• Overview of key technologies
• Email has the ability to scale structure over time, ranging from body text to structured attachments and explicit metadata MIME part
• Email as a transport has worked for a long time, but the content of a SMTP message can be the basis for innovation
• Based on the Security & Trust WG recommendations, there may be multiple policy environments where a provider could simultaneously be engaged
  • SMTP uses S/MIME to allow for this
• SMTP offers a scalable approach to PKI management
• Security agent allows for transport independence
• Walk through of a sample message
• Email brings a set of functionality that we believe is desired
• Since we’re talking about a distributed messaging network for the country, where nodes may be unavailable at certain points, the chosen NHIN Direct solution should be resilient to this sort of situation
  • SMTP as it exists today offers store and forward as a means to achieve this
• Overview of advantages to using existing services
• Walk through of demonstration from June 8th
  • Used DNS for certificate distribution
  • Secure Exchange Solutions, a company that already has a S/MIME based system, was able to successfully send and receive NHIN-D messages using the SMTP implementation
  • Have demonstrated use of a “desktop gateway”, leveraging existing live email services, for the SMTP implementation

Rich Elmore

• The SMTP model supports the little guy, but how would it interact with systems that have implemented IHE and make IHE transparent?
• Sean Nolan – There are many cases where interaction with IHE might not be relevant to the direct push transactions of NHIN Direct
  • SMTP offers the ability to bundle metadata in a XDM attachment. This allows for a natural exchange between SMTP and IHE/SOAP, as demonstrated by the IHE team.
  • Outside of IHE, there are many instances where SMTP could interact with NHIN Direct today

Wes Rishel

• We’ve spoken a great deal about the responsibility entailed when a message is passed from A-B. As you introduce multiple hops, how is this addressed?
• What about the model developed by Surescripts?
• Sean Nolan – Likely that Surescripts has invested a great deal of money into developing its system
  • SMTP bounces work really well if you bounce off of another NHIN Direct node because they can encrypt and sign against the same address
  • If you bounce off of a non-NHIN Direct node, the message would be dropped because it wouldn’t be signed

Overview of IHE/SOAP - provided by Peter DeVault

• Reasons for taking on IHE
  • Makes sense to leverage the work that has already been done in healthcare for EHR systems
  • However, it also makes sense that there may be use cases or provider situations where IHE implementations may not make the most sense
• Instead of demonstrating XDR end-end, we wanted to show the use of a SOAP-based backbone with other protocols on the edges
• Developers on the project described how easy it was to perform the transforms between the XDR backbone and non-XDR edge protocols
• Demonstrated four scenarios
  • EMR to EMR
  • EMR to Email - can address a number of the priority 1 NHIN Direct User stories
  • Email to PHR
  • Web app (RESTful) to Email
• To address the question of metadata:
  • IHE profiles provide a consistent place that is content-neutral to put metadata
  • Policy decisions pertaining to metadata could impact future user stories requiring metadata
  • If required by policy, IHE profiles can be degraded to have zero patient-specific metadata
• Key advantages of IHE:
  • IHE is a mature approach, small changes to XDR are preferable to inventing something new
  • Interoperability with NHIN Exchange is trivial using the IHE approach

Brett Peterson

• Is there an option to encrypt and sign all the way down to the source and destination?
• Peter DeVault – There is the capability to sign end-end, this will be discussed further tomorrow as part of the S&T discussion
• John Moehrke – SOAP supports message-level security
• Brett Peterson – Can the client do this level of encryption and encoding?
• John Moehrke – This may be difficult at the various step-up and step-down points. This is not a native function of XDR.
• Vassil Peytchev – You can send the S/MIME package over XDR
• Janet Campbell – You can do step-up and step-down without revealing patient information at the HISP and requiring trust at the HISP

Wes Rishel

• A HISP seems to be equated with a HIE in the IHE presentation, is this a requirement?
• Peter DeVault – This is definitely not a requirement. The only responsibility of the HISPs in the IHE demonstrations were to do transforms and routing
• Wes Rishel – Would these transforms result in patient data being revealed?
• Vassil Peytchev – Transforms require the generation or mapping of metadata, but there isn’t necessarily patient data in this metadata

Arien Malec

• Sounds like all of the options are moving in a similar direction – we should start with minimal routing data and attach XDM
• If we go this direction, what are the unique advantages of IHE?
• Peter DeVault – There are two primary advantages of IHE:
  • Gives us a future place to go when we encounter user stories where more metadata would make sense because IHE gives a consistent, structured place to put this metadata
  • Enables interoperability with NHIN Exchange
• Arien Malec - If I can attach a XDM package in a standard way across these protocols, how is IHE different?
• Peter DeVault – You will need to transform the XDM at some point, IHE would reduce the burden of transforming to XDR

Dan Kazzaz

• What happens when a provider doesn’t have an EMR, has generated a note and needs to send it to another provider? There is no metadata at the beginning in this situation.
• Peter DeVault – When there is no metadata, we don’t know what patient to associate the message with. You’d have to actually open the message to determine who the patient is

Overview of REST - provided by Brett Petersen and Mark Stine
Brett Peterson

• REST uses HTTP methods, applied to resources that are expressed as URIs
• Little programming knowledge needed to implement
• Note that the REST specification has been updated for clarity
• Three implementations
  • Ruby on rails
  • Java (Spring MVC)
  • Java (ANL)
• REST requires very little knowledge from the programmer’s perspective
• Technology used by REST is ubiquitous and has been used for a long time
• REST implementation uses a certificate REST resource rather than DNS
• Walkthrough of REST Scenario 1: REST Source to Email Destination and Reply
  • Message does not have metadata, information about patient is in the content
  • Reply goes through a HISP
  • Demonstrates exchange of unstructured attachments (PDF)

Mark Stine

• Walkthrough of REST Scenario 2: EHR to client
  • Uses existing message center within EHR product
• Integrated SMTP-developed security element into REST implementation
• Key implementation highlights:
  • Only took one week for one engineer to implement the Care360 EHR/HISP connectivity using REST
  • REST is standards-based
  • There is standard library support for REST

David McCallie

• Given that content is similar to SMTP, could you comment on the pros/cons of REST not having store/forward capabilities? How does REST approach these capabilities?
• Brett Peterson – You would have to create code to address this for a HISP implementation

Lin Wan

• How do you know what type of data a recipient is capable of receiving?
• Brett Peterson – A HISP hosting the email client could either provide a transform service or reject the message
• Lin Wan – The hard part is figuring out the address and what the recipient wants
• Brett Peterson – REST model puts a lot of ability in the hands of the HISP to provide added-value services - it’s a simple API that can be built upon

Tim Andrews

• We have a desire to get to small practitioners quickly, how long will it take the vendor community to make this available to providers?
• Arien Malec – The IHE team would say that the simplest thing to implement is what’s already been done. The SMTP team would say this is a solved problem, you simply install a SMTP server. The REST team would say that the API is simple and it’s not hard to build from scratch. We need to make a judgment on the tradeoffs of simplicity.

Wes Rishel

• If this whole exercise is about not letting the most complex use case drive the process, let’s not get caught up in the issue of providing transformation services
• We have a good idea of how to work with the edge, so now we’re really only looking at the HISP-HISP protocol
• How much does it matter if a protocol has been in use for a long time?
• Arien Malec – Declare this a discussion to be tabled for tomorrow

Overview of XMPP – provided by Nageshwara Bashyam

• Case for XMPP
  • Simple infrastructure requirements – just the internet and DNS
  • Easy to develop and integrate with existing systems
  • XMPP services achieve desired NHIN Direct transactions and also offer publish-subscribe capabilities
  • Supports TSL, SASL authentication/authorization and PKI using x509 certificates
  • Scalable with server federation
  • Can provide an innovation platform for the future of healthcare applications
• Walkthrough of demonstration from June 8th
• Addressing concerns/comments:
  • HITSC concern that XMPP approach doesn’t meet requirement to use x509 certificates
    • SASL is a framework, SASL external supports x509 certificates for authentication
  • XMPP presence feature may imply availability
    • There are four presence states available (away, available, busy, extended away)
    • Out of band file transfer can occur when the user is offline
  • Certificate model for interoperability between XMPP servers
    • Certificates typically need to be routed in the same CA to establish trust
  • Existing client and server software
    • Would need to create new software to interact with NHIN Exchange and with sources/destinations that are not associated with a HISP
    • Many open sources clients don’t support signing and encryption of messages

David Tao

• How much is XMPP used in EHRs/in a healthcare context?
• Nageshwara Bashyam – There is low adoption in EHRs, I specifically know of a single instantiation
• David Tao – Didn’t want to imply that XMPP would have to be built into a EHR, but at least one piece of certified EHR technology would have to include this for MU
• Nageshwara Bashyam – Instant messaging is widely used, but integration with health messages is not very prevalent
• Arien Malec – Proposal is not to have a chat window in a EHR, but to use the XMPP protocol in some way
• Lee Jones – Even though there may be prevalence of a protocol, we need to think about the likelihood of a vendor to advance that solution for a certified product
  
  

HITSC Review and Feedback – Overview given by Arien Malec:

• Received positive feedback from the concrete implementation WG to obtain external review of the implementation options
• During a subsequent HIT Standards Committee meeting, asked the HITSC to put together a small review group, this group included: Jon Halamka, Stan Huff, Ken Mandl, Carol Diamond, Dixie Baker, and Ashley Corbin
• HITSC review group represented both standards and policy perspectives
• We asked the HITSC review group to give feedback on the strong/weak aspects of the implementation proposals, the decisional criteria, the suitability of each implementation to meet project goals given the criteria, and to give a recommendation to the implementation group
• We told the review group that we would take their feedback to the Implementation Group for strong consideration
  • From a process perspective, we should think about the feedback from the review group as input to the Implementation Group’s decision
  • Personally surprised that the HITSC review group came to a consensus decision
• HITSC review group recommended:
  • Further development of REST implementation as the backbone and with SMTP email provided by the HISP
  • No implementation should move forward to a pilot without the establishment of a policy framework
• NHIN Direct discussion with policy representatives has been very constructive to date
• HITSC review of IHE:
  • Believed to be overly complex
  • XDR is meant for patient specific exchange, though some MU scenarios may involve non-patient specific exchanges
  • Concern about minimizing disclosure of PHI
  • Should be able to enable interoperability without revealing PHI
    • IHE approach unnecessarily exposes and manipulates PHIE
• HITSC review of REST:
  • Specification not clear about use of TLS
  • Simple
  • Only accommodates asymmetric encryption
• HITSC review of SMTP
  • If we’re using an open email system, it may not enable appropriate security control
  • Difficult to integrate with NHIN Exchange
• HITSC review of XMPP
  • Likely was unfairly excluded
  • There was a technical misunderstanding about use of SASL external mechanism
• Privacy and Security tiger team will do an evaluation based on privacy requirements
• We should honor the feedback from the HITSC review group as representatives chosen by the nation for the HITSC

Don Jorgenson

• What is meant by waiting until a policy framework is in place?
• Arien Malec – We should not move forward to pilot without having such a framework in place
• Claudia Williams – There was a designation in ARRA that the HITPC would provide guidance on developing policy considerations that may be incorporated into NHIN Direct solution
• Arien Malec – There is a question of whether this is a barrier or a blessing to what we’re doing. The members of these committees believe that technology and policy are inseparable.

David Tao

• The HITSC review group found bugs with every approach, but some of these conclusions were incorrect/misunderstandings. Concerned that if these decisions have already been made, not every team got an accurate assessment.
• Arien Malec – We should take a look at the requirements defined by the HISTC review group, including the separation of access to metadata, the ability for a HISP to operate without access to PHI, simplicity, and the ability for end-end communication
  • We should consider the HITSC recommendation, but if we think it’s wrong, we should at least be able to honor the requirements they set forth
  • The HITSC will have to review the NHIN Direct standards at the end of this process, so we need to make sure that we understand and address their requirements throughout our own development process
• David McCallie – The HITSC review group seemed to request our feedback on the review process
• Arien Malec – If there is feedback for the HITSC, please route this feedback through Jackie or on the wiki page for today’s meeting

Lee Jones

• Seems like there is a desire to blend solutions. We originally stated that we wanted to drive to one solution, is it back on the table to endorse more than one solution?
• Arien Malec – We can do whatever we want within this group. We need to honor the requirements that have been expressed by the HITSC and the eventual policy framework set forth by ONC.
• Brian Behlendorf – However, we do need to come down to a common way to do something. If we have more than one backbone, this becomes a requirement for a HISP to do both. We need to come to a solution that is easy for the pilot teams to implement.
• Arien Malec – If you do too many things, you introduce complexity and security vulnerabilities.
  • The review group believed in simplicity, both in terms of approach and in not allowing too much variation
• Lee Jones – The idea of simplicity is theoretical, not empirical, at the moment

Peter DeVault

• Is there a mandate that everything in MU that looks like a push transaction needs to be addressed by the implementations?
• Arien Malec – Following the review, I looked back at where we assigned priorities to certain NHIN Direct user stories. We put these on the table.
• This was not a major criteria for the HITSC review group.
• Peter DeVault – We need to clarify the user stories

Tim Andrews

• Isn’t everyone ultimately required to do an IHE backbone if we need to interoperate with NHIN Exchange?
• Arien Malec – Many organizations will want to do functions supported by NHIN Exchange, but this doesn’t preclude other approaches from presenting new ways to do this.
• Tim Andrews – Not clear on HITSC concern with SMTP security
• Arien Malec – The concern raised by the review group was that if you allow a user to configure their everyday email client, you’re putting a lot of security configuration decisions in the hands of a person who may not be qualified to make such decisions
  • The agent approach relies on the HISP
  • Dixie’s perspective is: My ordinary email client is used for many things, one of which could be NHIN Direct. We‘re relying on the provider to choose which email account to use for which situation.
  • Sean Nolan – This factual error is based on the fact that the review group didn’t have a lot of time for their review

John Moehrke

• Concerned about the inconsistency of HITSC review approach

Wes Rishel

• The HITSC review introduced the fact that there is a considerable opportunity to improve our discourse. This is not surprising considering that the review group was asked to come into 100+-person process without a lot of opportunity to ask questions. Would be good if we could take some input from the review group that we wouldn’t perceive as having errors. We should take the group’s input and document our considerations.

David Kibbe

• On behalf of the American Academy of Family Physicians, I’m impressed by everyone’s efforts to do this right. The end result of this project will be beneficial to many physicians.
• How can something be too simple? We need to start with something that exists now and works, then do what’s needed to make it better.
• Uncomfortable with the idea that we have to pick one solution
• Hope that we’re not excluding secure protocols that work in the real world
• Arien Malec – Dixie’s comment of “too simple” was not from an implementation perspective, but from a security perspective

Will Ross

• When we wrote the user stories, we declared as out of scope anything that was not simple push. This was a self-imposed limitation based on our need to get something done.
• This feedback from the HITSC review group is an opportunity to correctly focus our work on the committee’s concerns.
• Arien Malec – In the hierarchy of concerns, addressing non-patient specific user stories was not one of the HITSC review group’s primary concerns. It would be useful to have a set of capabilities that allowed for both simple push of patient information as well as push of non-patient specific information (quality reporting).

Claudia Williams

• It’s natural when you’ve been developing something to argue your particular case against feedback
• It would be good to abstract the HITSC review group’s requirements and consider these requirements for tomorrow’s decision
• We must take seriously the implementation costs of complexity at scale

Vassil Peytchev

• I didn’t see one member of the HITSC review group participating in the June 8th Concrete Implementation WG review session. It would be good to have the review group participate in such sessions.
• Arien Malec – This was a function of the reviewers’ time
  • More dialogue with the HITSC would be useful
  • This particular review will likely be an initial step of active engagement from the HITSC

Dan Kazzaz

• Want to echo David Kibbe. This is a very impressive group, but we still have a long ways to go. These are hard problems that we need to address.

John Moehrke

• As much as it frustrates anyone to receive feedback on work they’ve produced, the particularly frustrating part was to attend the HITPC meeting this morning where the HITSC review group’s feedback was presented as gospel. The output of the review group was presented as a conclusion, when we haven’t had a chance to respond.
• Arien Malec – Will communicate this to Dixie

Wrap-Up & Agenda for Next Day provided by Arien Malec
· This has been a good level-setting day