Concrete Implementation HITSC Review Agenda & Notes from 06072010 Meeting
Jump to navigation
Jump to search
Notes
HITSC reviewers were provided with the following review materials in advance of the meeting: http://nhindirect.org/HITSC+Review
Arien Malec provided an overview of the NHIN Direct concrete implementation review process to the HITSC reviewers and requested that they ask any questions about the process.
Question from Carol Diamond
· Did you go into the NHIN Direct project thinking that there would be four different models?
· Arien Malec - We knew that we would want to explore different technologies
o We have four teams who believe strongly that each of their models is the way to proceed. We wanted to give fair consideration to each of these models.
o Originally we were hoping that 1-2 models would stand out, but instead we have four strong contenders
o We’re still determining whether multiple modalities should be explored
· Carol Diamond – So the goal is not to get to one model?
· Arien Malec – We’re looking for the HITSC review group to provide a recommendation that can help us get to either get to one or multiple options
· John Halamka – If we can narrow down the considerations, would that be helpful?
· Arien Malec – We’re looking for a parsimonious approach to identify a model that meets the goals of the project and has the lowest associated implementation, technical, and policy risk
· David McCallie – A core goal of NHIN Direct is universal addressing, which can be performed in different ways.
· Arien Malec – There can be many ways to achieve one thing
· Brian Behlendorf – We’re aiming for something simple and lightweight enough that it can be widely implemented
o A specification that says that there are more than one possible protocols in practical terms becomes a requirement to implement both
· Arien Malec - There is a cost to having multiple options
Question from Dixie Baker
· If we support multiple approaches, won’t this impede interoperability?
· Arien Malec – Our intent is a universal addressing approach that supports different protocols
· Dixie Baker – Are these addresses to an organization or an individual?
· Arien Malec – They are to an endpoint, which is a term we use in as all-encompassing a manner as possible. The different types of endpoints are grounded in the NHIN Direct user stories, many of which involve sending messages to an individual provider. However, some user stories may involve sending information to a practice rather than an individual provider.
· John Moehrke – Currently the addressing model is fairly abstract, we will be able to narrow in on this once we select the concrete model(s)
Question from Dixie Baker
· Are we evaluating to a moving target?
· Arien Malec – No, you are evaluating a set of well-defined options.
o As we narrow in on the concrete models, there will be some fine-tuning to the specifications
o Each option has testable code
Question from Ken Mandl
· How does NHIN Direct relate to other NHIN efforts and how quickly you do expect to see adoption of the results from this project?
· Arien Malec – The current set of NHIN specs provide for a node-node push of information. This type of transaction doesn’t allow for direct routing to a specific end destination
o Sending a message from one address to another is a desirable capability that isn’t solved by the current NHIN Exchange specifications or any existing well-recognized standards. This capability maps to stage 1 Meaningful Use (MU), quality access, and efficiency outcomes.
o At scale, there will be robust use of these direct services, as well as record locator and information access services. NHIN Direct will offer a new capability that will solve a new set of use cases.
o As far as our goals for adoption, the NHIN Direct capability should be deployable enough that it can be rolled out within the stage 1 MU timeline
· Ken Mandl – Could you clarify the adoption timeframe?
· Arien Malec – NHIN Direct capabilities should be broadly accessible by 2011. Use of these capabilities would be one of the ways a provider could meet stage 1 MU criteria.
Question from Carol Diamond
· From a policy perspective, the implementation options could quickly be narrowed. Is this the jurisdiction of this group, the policy committee, or the tiger team?
· Arien Malec –The NHIN Direct Implementation Group will decide in terms of NHIN Direct project which specs to move forward with. By the end of the project, we should have a set of specs that can be turned into standards for consideration by the standards committee. This HITSC review is intended to provide independent, third party expert review and feedback to the implementation group. We’re not expecting the HITSC to make a decision about the implementation options at this point.
Comment from Arien Malec
· Propose to proceed with overviews for each of the four concrete implementation options. Each team may have a member provide this overview on behalf of their team.
Overview of IHE – given by Karen Witting
· Team started with the protocol existing in NHIN Exchange, XDR, and adapted this to support the NHIN Direct use cases
· We are profiling how metadata will be used for NHIN Direct
· Have looked at how a variety of edge protocols can be used with a XDR backbone. Demonstrating both use of SMTP and REST on edge with XDR as the backbone.
· A benefit of IHE is that it provides good metadata. This is important because it allows receiver to properly handle a message.
Overview of REST – given by Brett Peterson
· Team took the approach of exposing services through the simplest mechanism available, using HTTP as the mechanism and REST as the style
· REST is in production in both healthcare and non healthcare settings
· Adopted content container specification to use multi-part mail messages for content
· Team thought it was important to separate backbone from edge. Have both a HTTP edge protocol and a SMTP edge protocol to allow for vendor integration and email communication. REST serves as the backbone for both of these edge options.
· REST approach uses TLS for privacy and S/MIME for solving authentication, privacy, and non-repudiation from endpoint to endpoint
· Also found a way to distribute x509 certificates using REST
· NHIN Exchange node integration can be done using adapters
Overview of SMTP– given by Sean Nolan
· Noticed common desire among providers to use email for healthcare communications. SMTP team would need to address certain security and privacy concerns.
o Decided to reuse existing email work and add a layer that implements security, privacy, and spam control that is appropriate for healthcare data.
o Believe approach will address policy concerns and allow for flexibility to adapt to any changes in policy
· Email clients are not the only way to interact, the majority of EHRs already have some email integration
· Because SMTP has taken the same multi-part approach that Brett mentioned, SMTP would be able to support both structured and unstructured content
Overview of XMPP – given by Arien Malec
· XMPP is a messaging and presence standard based on the open source Jabber IM software.
· Supports open IM as well as private server messaging
· XMPP team used same content container spec as the other teams, along with the ability to secure content using S/MIME
· XMPP is widely available with a wide set of libraries. There is also a good amount of existing art for how to compose services.
Questions from HITSC Reviewers
Question from John Halamka
· For each option, there is a need to identify endpoints. Certificate management has been nightmareish. Do any of the four options offer an approach certificate management to make this easier?
· Brian Behlendorf – The abstract model introduces the concept of a HISP, which provides certain services to endpoints. These HISPs can handle crypto and key-management functions.
Responses from Concrete Implementation Teams:
· Karen Witting (for IHE team) – IHE team is considering putting certificates into a provider directory
· John Moehrke (for IHE team) – The most complex part is the issuance of certificates, which is a common issue across all options. Providers will have to take responsibility for obtaining certificates from some authority.
o IHE model uses widely-leveraged TLS model, all you need to do is validate certificates
o Advantage is that certificates are distributed in real-time as part of this protocol
o IHE also supports message-based security, but here you would need to distribute certificates separately
· Dixie Baker – While TLS does provide access to certificates that have been signed, it doesn’t provision certificates
· John Moehrke (for IHE team) – That is correct, certificates must be provisioned no matter what model
· Brett Peterson(for REST team) – From the REST perspective, we’ve chosen a message-based security approach
o After some analysis, we believe TLS can only be used for HISP-HISP privacy
o In order to distribute certificates in a real-time capacity, we added a new URL which returns to a caller all certificates for that endpoint
· Arien Malec (for REST team) – If you trust your HISP to manage your identity on your behalf, the HISP could automatically expose certificates through this. If not, you have the same certificate distribution challenge.
· Sean Nolan (for SMTP team) – SMTP security approach is similar to REST, with a difference in distribution
o The challenge of certificate management comes down to the ability of organizations to create right-scale processes to manage artifacts
o Certificates can be managed from anywhere in the chain of HISP-to-organization-to-individual
o Someone needs to do identity proofing/managing conformance to policies
· Arien Malec (for XMPP team) – XMPP approach is similar to SMTP, relies on the same infrastructure
· David McCallie – This is a policy consideration, but there can be multiple kinds of certificates in use. The primary purpose of these certificates is to ensure that mail is delivered securely, not necessarily to also prove identity.
· Arien Malec – In theory, these same certificates could also be used for transactions requiring identity proofing.
Question from Dixie Baker
· Do teams other than the REST team also address non repudiation?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – IHE has a few non-repudiation models
Question from Dixie Baker
· Are all exchanges document based?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – Yes, the IHE team has always considered that both sides, receiver and sender, need to be authenticated
· Dixie Baker – Does that not refer to digital signatures?
· John Moehrke (for IHE team) – Digital signature is a broad term
· Dixie Baker – I’m referring to the digital signing of content
· John Moehrke (for IHE team) – All of the approaches are similar in terms of digital signing of content
· Karen Witting (for IHE team) – Note that a document can be either unstructured or structured in the IHE world
· Arien Malec – Speaking for the SMTP, REST and XMPP teams: Wrapping content using S/MIME gives the ability to put a standard digital signature on content.
o This function could be done by a provider or a HISP on behalf of the provider
o In most cases, non-repudiation will be HISP-HISP rather than provider-provider
· Sean Nolan (for SMTP team) – You will get a level of non-repudiation commensurate with the level of granularity provided at the provider organization level
· John Moehrke (for IHE team) - IHE supports this same level of granularity
Question from John Halamka
· How does management of metadata differ among the four options?
Responses from Concrete Implementation Teams:
· Arien Malec – XMPP only exposes standard XMPP metadata
o Both REST/SMTP can either expose lots of metadata or only routing information
· Vassil Peytchev (for IHE team) - IHE can provide the same level of exposure using transport-layer addressing as any of the other protocols
o However, I believe that John’s question was regarding how to manage metadata
· David McCallie (for SMTP team) – The REST and XMPP approaches both assume that if robust metadata is required, it addressed by wrapping using a XDM wrapper
Question from Carol Diamond
· Metadata raises big policy questions. Where do metadata exposure decisions happen?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – We need to separate technology from policy. The only reason a HISP exists is to assist in facilitating simple transactions for providers as needed. When this convenience is needed, strong policies should be placed on that organization.
· Arien Malec – I think this question goes back to a fundamental scenario we’ve been wrestling with: I just want to outsource the transaction handling portions of an exchange while also protecting content so that the handler can’t see it. REST, SMTP and XMPP can all allow for this.
· Carol Diamond – The real question is not can I do that, but should I do that.
Notes from HITSC Review of Concrete Implementations: Part I
Date: June 7, 2010
Time: 12pm-1pm
Attendees: Jackie Key, Carol Diamond, Arien Malec, Brian Behlendorf, Brett Peterson, Christopher Moyer, David McCallie, Dixie Baker, Doug Fridsma, Eric Heflin, Ioana Singureanu, Jack Ousey, John Halamka, Karen Witting, Ken Mandl, Lee Jones, Rich Kernan, Sean Nolan, Susan Nelson, Vassil Peytchev, Wenzhi Li, CMS representatives (names not captured), John Moehrke
Agenda
- Overview/thank you and any overall process questions from HITSC reviewers (10 mins)
- HITSC reviewers to ask questions about each implementation (40 mins/10 mins per implementation)
- General Q&A for reviewers (10 mins)
Notes
HITSC reviewers were provided with the following review materials in advance of the meeting: http://nhindirect.org/HITSC+Review
Arien Malec provided an overview of the NHIN Direct concrete implementation review process to the HITSC reviewers and requested that they ask any questions about the process.
Question from Carol Diamond
· Did you go into the NHIN Direct project thinking that there would be four different models?
· Arien Malec - We knew that we would want to explore different technologies
o We have four teams who believe strongly that each of their models is the way to proceed. We wanted to give fair consideration to each of these models.
o Originally we were hoping that 1-2 models would stand out, but instead we have four strong contenders
o We’re still determining whether multiple modalities should be explored
· Carol Diamond – So the goal is not to get to one model?
· Arien Malec – We’re looking for the HITSC review group to provide a recommendation that can help us get to either get to one or multiple options
· John Halamka – If we can narrow down the considerations, would that be helpful?
· Arien Malec – We’re looking for a parsimonious approach to identify a model that meets the goals of the project and has the lowest associated implementation, technical, and policy risk
· David McCallie – A core goal of NHIN Direct is universal addressing, which can be performed in different ways.
· Arien Malec – There can be many ways to achieve one thing
· Brian Behlendorf – We’re aiming for something simple and lightweight enough that it can be widely implemented
o A specification that says that there are more than one possible protocols in practical terms becomes a requirement to implement both
· Arien Malec - There is a cost to having multiple options
Question from Dixie Baker
· If we support multiple approaches, won’t this impede interoperability?
· Arien Malec – Our intent is a universal addressing approach that supports different protocols
· Dixie Baker – Are these addresses to an organization or an individual?
· Arien Malec – They are to an endpoint, which is a term we use in as all-encompassing a manner as possible. The different types of endpoints are grounded in the NHIN Direct user stories, many of which involve sending messages to an individual provider. However, some user stories may involve sending information to a practice rather than an individual provider.
· John Moehrke – Currently the addressing model is fairly abstract, we will be able to narrow in on this once we select the concrete model(s)
Question from Dixie Baker
· Are we evaluating to a moving target?
· Arien Malec – No, you are evaluating a set of well-defined options.
o As we narrow in on the concrete models, there will be some fine-tuning to the specifications
o Each option has testable code
Question from Ken Mandl
· How does NHIN Direct relate to other NHIN efforts and how quickly you do expect to see adoption of the results from this project?
· Arien Malec – The current set of NHIN specs provide for a node-node push of information. This type of transaction doesn’t allow for direct routing to a specific end destination
o Sending a message from one address to another is a desirable capability that isn’t solved by the current NHIN Exchange specifications or any existing well-recognized standards. This capability maps to stage 1 Meaningful Use (MU), quality access, and efficiency outcomes.
o At scale, there will be robust use of these direct services, as well as record locator and information access services. NHIN Direct will offer a new capability that will solve a new set of use cases.
o As far as our goals for adoption, the NHIN Direct capability should be deployable enough that it can be rolled out within the stage 1 MU timeline
· Ken Mandl – Could you clarify the adoption timeframe?
· Arien Malec – NHIN Direct capabilities should be broadly accessible by 2011. Use of these capabilities would be one of the ways a provider could meet stage 1 MU criteria.
Question from Carol Diamond
· From a policy perspective, the implementation options could quickly be narrowed. Is this the jurisdiction of this group, the policy committee, or the tiger team?
· Arien Malec –The NHIN Direct Implementation Group will decide in terms of NHIN Direct project which specs to move forward with. By the end of the project, we should have a set of specs that can be turned into standards for consideration by the standards committee. This HITSC review is intended to provide independent, third party expert review and feedback to the implementation group. We’re not expecting the HITSC to make a decision about the implementation options at this point.
Comment from Arien Malec
· Propose to proceed with overviews for each of the four concrete implementation options. Each team may have a member provide this overview on behalf of their team.
Overview of IHE – given by Karen Witting
· Team started with the protocol existing in NHIN Exchange, XDR, and adapted this to support the NHIN Direct use cases
· We are profiling how metadata will be used for NHIN Direct
· Have looked at how a variety of edge protocols can be used with a XDR backbone. Demonstrating both use of SMTP and REST on edge with XDR as the backbone.
· A benefit of IHE is that it provides good metadata. This is important because it allows receiver to properly handle a message.
Overview of REST – given by Brett Peterson
· Team took the approach of exposing services through the simplest mechanism available, using HTTP as the mechanism and REST as the style
· REST is in production in both healthcare and non healthcare settings
· Adopted content container specification to use multi-part mail messages for content
· Team thought it was important to separate backbone from edge. Have both a HTTP edge protocol and a SMTP edge protocol to allow for vendor integration and email communication. REST serves as the backbone for both of these edge options.
· REST approach uses TLS for privacy and S/MIME for solving authentication, privacy, and non-repudiation from endpoint to endpoint
· Also found a way to distribute x509 certificates using REST
· NHIN Exchange node integration can be done using adapters
Overview of SMTP– given by Sean Nolan
· Noticed common desire among providers to use email for healthcare communications. SMTP team would need to address certain security and privacy concerns.
o Decided to reuse existing email work and add a layer that implements security, privacy, and spam control that is appropriate for healthcare data.
o Believe approach will address policy concerns and allow for flexibility to adapt to any changes in policy
· Email clients are not the only way to interact, the majority of EHRs already have some email integration
· Because SMTP has taken the same multi-part approach that Brett mentioned, SMTP would be able to support both structured and unstructured content
Overview of XMPP – given by Arien Malec
· XMPP is a messaging and presence standard based on the open source Jabber IM software.
· Supports open IM as well as private server messaging
· XMPP team used same content container spec as the other teams, along with the ability to secure content using S/MIME
· XMPP is widely available with a wide set of libraries. There is also a good amount of existing art for how to compose services.
Questions from HITSC Reviewers
Question from John Halamka
· For each option, there is a need to identify endpoints. Certificate management has been nightmareish. Do any of the four options offer an approach certificate management to make this easier?
· Brian Behlendorf – The abstract model introduces the concept of a HISP, which provides certain services to endpoints. These HISPs can handle crypto and key-management functions.
Responses from Concrete Implementation Teams:
· Karen Witting (for IHE team) – IHE team is considering putting certificates into a provider directory
· John Moehrke (for IHE team) – The most complex part is the issuance of certificates, which is a common issue across all options. Providers will have to take responsibility for obtaining certificates from some authority.
o IHE model uses widely-leveraged TLS model, all you need to do is validate certificates
o Advantage is that certificates are distributed in real-time as part of this protocol
o IHE also supports message-based security, but here you would need to distribute certificates separately
· Dixie Baker – While TLS does provide access to certificates that have been signed, it doesn’t provision certificates
· John Moehrke (for IHE team) – That is correct, certificates must be provisioned no matter what model
· Brett Peterson(for REST team) – From the REST perspective, we’ve chosen a message-based security approach
o After some analysis, we believe TLS can only be used for HISP-HISP privacy
o In order to distribute certificates in a real-time capacity, we added a new URL which returns to a caller all certificates for that endpoint
· Arien Malec (for REST team) – If you trust your HISP to manage your identity on your behalf, the HISP could automatically expose certificates through this. If not, you have the same certificate distribution challenge.
· Sean Nolan (for SMTP team) – SMTP security approach is similar to REST, with a difference in distribution
o The challenge of certificate management comes down to the ability of organizations to create right-scale processes to manage artifacts
o Certificates can be managed from anywhere in the chain of HISP-to-organization-to-individual
o Someone needs to do identity proofing/managing conformance to policies
· Arien Malec (for XMPP team) – XMPP approach is similar to SMTP, relies on the same infrastructure
· David McCallie – This is a policy consideration, but there can be multiple kinds of certificates in use. The primary purpose of these certificates is to ensure that mail is delivered securely, not necessarily to also prove identity.
· Arien Malec – In theory, these same certificates could also be used for transactions requiring identity proofing.
Question from Dixie Baker
· Do teams other than the REST team also address non repudiation?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – IHE has a few non-repudiation models
Question from Dixie Baker
· Are all exchanges document based?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – Yes, the IHE team has always considered that both sides, receiver and sender, need to be authenticated
· Dixie Baker – Does that not refer to digital signatures?
· John Moehrke (for IHE team) – Digital signature is a broad term
· Dixie Baker – I’m referring to the digital signing of content
· John Moehrke (for IHE team) – All of the approaches are similar in terms of digital signing of content
· Karen Witting (for IHE team) – Note that a document can be either unstructured or structured in the IHE world
· Arien Malec – Speaking for the SMTP, REST and XMPP teams: Wrapping content using S/MIME gives the ability to put a standard digital signature on content.
o This function could be done by a provider or a HISP on behalf of the provider
o In most cases, non-repudiation will be HISP-HISP rather than provider-provider
· Sean Nolan (for SMTP team) – You will get a level of non-repudiation commensurate with the level of granularity provided at the provider organization level
· John Moehrke (for IHE team) - IHE supports this same level of granularity
Question from John Halamka
· How does management of metadata differ among the four options?
Responses from Concrete Implementation Teams:
· Arien Malec – XMPP only exposes standard XMPP metadata
o Both REST/SMTP can either expose lots of metadata or only routing information
· Vassil Peytchev (for IHE team) - IHE can provide the same level of exposure using transport-layer addressing as any of the other protocols
o However, I believe that John’s question was regarding how to manage metadata
· David McCallie (for SMTP team) – The REST and XMPP approaches both assume that if robust metadata is required, it addressed by wrapping using a XDM wrapper
Question from Carol Diamond
· Metadata raises big policy questions. Where do metadata exposure decisions happen?
Responses from Concrete Implementation Teams:
· John Moehrke (for IHE team) – We need to separate technology from policy. The only reason a HISP exists is to assist in facilitating simple transactions for providers as needed. When this convenience is needed, strong policies should be placed on that organization.
· Arien Malec – I think this question goes back to a fundamental scenario we’ve been wrestling with: I just want to outsource the transaction handling portions of an exchange while also protecting content so that the handler can’t see it. REST, SMTP and XMPP can all allow for this.
· Carol Diamond – The real question is not can I do that, but should I do that.