Concrete Implementation HITSC Review Agenda & Notes from 06092010 Meeting
Jump to navigation
Jump to search
Materials:
HITSC Review Results:
Notes
HITSC reviewers were provided with the following review materials in advance of the meeting: http://nhindirect.org/HITSC+Review
Arien Malec
· Both the HIT Standards Committee (HITSC) and HIT Policy Committee’s (HITPC) Privacy and Security tiger team are undertaking parallel processes that will incorporate feedback from this HITSC review group
· The Implementation Group will recommend a set of specifications for NHIN Direct to move forward with as these processes occur in parallel
o Note that this decision may not meet the eventual requirements defined by the HITSC and HITPC
o These committees will inform us of any gaps between the NHIN Direct specifications and the HITSC and HITPC requirements and we’ll work to address these gaps
· NHIN Direct is aiming for a robust set of nationwide capabilities in support of MU and other improved healthcare outcomes identified by ARRA
o Feedback from HITSC and HITPC will help us to deploy these capabilities
· We realize that from a timing perspective, the feedback process is a bit backward
Paul Egerman
· The process is not ideal, but it’s interesting to do policy and technology in parallel so that the policy can realistically reflect what technology can accomplish
· We’ll try to harmonize the work of NHIN Direct with the policy work
John Halamka
· We recognize that policy and technology are being done in parallel
· If we had more time, we might have tried to do policy ahead of time
· For her evaluation of the four options, Dixie has compared the four implementations against the following:
o Consensus requirements for NHIN Direct
o Policy requirements
· We wanted to first ensure that the consensus requirements are met by implementations, then once we’d understood the implementations’ strengths and weaknesses against these requirements, identify the simplest option
Dixie Baker
· While our assessment was based on the NHIN Direct consensus requirements, we recognize that these requirements were established in absence of a policy framework
· Our assessment was done assuming that the consensus requirements could change as policies are defined
· For our security assessment, simplicity is not an “also”, it’s essential. Complexity breeds vulnerabilities.
Compliance with Consensus Requirements:
· We first looked at the four implementations with the consensus requirements as a yardstick
· We did not feel that XMPP meets the requirements
o XMPP implementation does not use x509 certs for authentication, but uses SASL
o Don’t believe XMPP should be further considered
· We thought that the remaining three implementations are compliant with the consensus requirements
Simplicity:
· IHE exposes PHI and manipulates PHI unnecessarily in order to generate metadata for sending documents
· While metadata adds value, it also presents unnecessary risks
o Confidentiality – PHI is exposed more than necessary
o Integrity – PHI is manipulated more than necessary
· IHE solution is overly complex, doesn’t meet simplicity requirement
· Relies on XDR and XDS, which were designed for the exchange of patient specific information
o Many MU reporting scenarios are not patient specific
· Both REST and SMTP meet the consensus requirements and both are simple.
o We’d like to see these two solutions coexist
· Concerned that SMTP leaves too much enforcement at the discretion of the user
· Would rather see a NHIN account that is accessible through the HISP, allowing the HISP to manage enforcement and not leaving this to the client
· Would like to see both REST and SMTP taken forward as an integrated solution
John Halamka
· We made our evaluation from a policy and requirements driven perspective
· We first looked whether each implementation met the consensus requirements (XMPP did not), then looked at simplicity (IHE was not simple)
· The idea of a RESTful implementation where SMTP could be offered by a HISP, not having just SMTP at the edge, seems like the best combination
Dixie Baker
· No implementation should move forward without the policy framework and validated security requirements in place
· The tiger team is on an aggressive schedule that shouldn’t delay the implementation
John Halamka
· IHE has a valuable place, but in the case of the simplicity required for edge-edge transmission, it did not seem to fit
· REST with a SMTP offering from the HISP seemed to offer the best balance
Carol Diamond
· From the policy side, Dixie got it right
· The notion of having a policy framework creates expectations that the disclosure of information should be minimized
David McCallie
· Should we debate now and respond to the HITSC evaluation?
Arien Malec
· Keep in mind that this is a preliminary recommendation, not a final recommendation or decision
· Note that the parallel HITSC and HITPC processes may introduce new requirements or clarity
Carol Diamond
· I think a Q&A session would be helpful
Responses from Concrete Implementation Teams to HITSC Review
Nageshwara Bashyam
· Looking at the statement that SASL doesn’t conform with x509 requirements
· SASL is an authentication mechanism
· XMPP approach uses the SASL external mechanism, which supports x509 certificates
· Maybe I didn’t clarify this well in the XMPP capability worksheet
Dixie Baker
· If SASL is a fundamentally a challenge response protocol, how are x509 certs used?
· Nageshwara Bashyam - Challenge response is one of the options
o You can have a client certificate and a server certificate
· Arien Malec – The SASL external specification says that we’ve already handled authentication at a lower level of the stack (via TLS)
Peter DeVault
· Concerned that the review was done using the capability worksheets as they were last week. The teams only first presented their work in a complete, unified way yesterday.
· Yesterday the IHE team showed that REST and SMTP can be used on the edge, with XDR as a backbone. We demonstrated that having XDR as a backbone offers several advantages, including interoperability with NHIN Exchange.
· The only place PHI-containing metadata might be visible would be at a trusted intermediary, such as a HISP
Karen Witting
· There are many ways PHI could be protected
· Metadata is important. The IHE team feels that the other implementations have too little metadata, which will be problematic
· Our model allows us to identify a minimal metadata set which could be further constrained based on policy requirements
· Confused by the mention of patient-specific information, wasn’t every NHIN Direct use case about patient-specific transactions
· John Halamka - When we look at MU data exchanges, there are transactions where packages or summary-level data are pushed
· Arien Malec - The NHIN Direct user stories as written do include quality reporting, but these were given lower priority relative other user stories
· John Halamka - GIPSE packages or PQRI packages wouldn’t necessarily be patient specific
o How do you generically transport these packages securely from a small guy?
· Doug from CMS -We’re talking about NHIN Direct. CMS will not receive information from NHIN Direct but from NHIN Exchange.
· John Halamka – A provider would use the simple NHIN Direct protocol to send data to an intermediary and then the intermediary could route this appropriately
· Doug from CMS –An EHR vendor could also perform this function
· Vassil Peytchev - What you have described validates the point that transformations from NHIN Direct to NHIN Exchange will have to happen. This extra step might comprise security.
· Doug from CMS –There were no certificates in these examples. With NHIN Exchange there are certificates and they are encrypted.
Dixie Baker
· The idea is that NHIN Direct is supposed to be the most simple transport from A-B, with value-added services potentially provided in-between, but NHIN Direct wouldn’t be concerned with the provision of these services
· Doug from CMS - Not sure how NHIN Direct plays into HCR and MU
John Halamka
· I see NHIN Direct as a set of tools that could be made available to small providers as part of their arsenal to perform exchanges for MU
· We are on a timeframe to get running code available in time for providers to use for MU
· Arien Malec - The intent of NHIN Direct is to provide an electronic means for providers to achieve this
John Halamka
· We should think about how we can be as thin as possible on the edges and also ensure security
Lee Jones
· What is meant by simple?
· Dixie Baker – Even just listing the number of functions that a HISP provides under IHE, IHE provides many more functions than the other options. Given that the function we’re supposed to provide is to get a document from A-B securely, anything beyond this is more than simple
· John Halamka – If I ask a programmer to complete a RESTful implementation of code, it takes less than a day. If I ask someone to complete a SOAP implementation, it takes longer. RESTful implementations are easier for programmers to program and debug.
· Paul Egerman– This definition of simple relates to technical simplicity, as opposed to simplicity from the user’s perspective
· Dixie Baker – What you really want is for the behavior exposed to the end user to be simple for them.
o Something can be complex under the covers but simple to the user.
· Lee Jones – Complexity to the user is the same for all of these implementations.
o The user interface (UI) will mask this for all users.
o We have to account for what different vendors who are providing these interfaces have already and integration to the rest of their healthcare offerings. Even for a simple, no healthcare technology deployed at the edge scenario, there’s still work to be done.
· Peter DeVault – Simplicity has been spoken about in a variety of ways. One is for the programmer, one is in terms of moving parts/vulnerability, and one is simplicity from the provider’s point of view
o It’s true that all transport protocols are equally simple to use with a client
o The user stories we’re addressing aren’t only for provider-provider, but for healthcare organizations – health care organizations in general. In this case, NHIN Direct must be simple for a single provider and an organization using an EHR.
o This is why it’s important to be able to vary the edge protocol and keep a common backbone. Simplicity isn’t always just technology.
· John Halamka – When we conducted our review, we may have each had a different internal definition of simplicity.
o We assumed the user interfaces for the doctor would look similar
o Many stakeholders (EHR vendors, aggregators, decision support, etc) will all be trying to do simple point-point push, so how do we identify the simplest implementation.
o IHE is very useful for pull transactions with government players
o We looked for the options with the fewest moving parts, fewest functions, and ease of implementation
· Dixie Baker – Also, we cared about the fewest user-made decisions that could impact security
o This was the concern with SMTP
o You want the easiest thing for the user to do to also be safest thing
Eric Heflin
· Important for us to focus on the decision before us for this week
· The decision before us is only to decide on the HISP-HISP backbone protocol, not the edge protocols. There have been comments regarding end user issues, but simplicity for the end user is not relevant to the backbone. Concerned that the backbone is being oversimplified, it’s legitimate for the backbone to be more sophisticated. If we constrain the functionality of the backbone, it can never be added back in.
John Halamka
· If a provider knows the IP address of another provider, is a HISP a necessary part of a NHIN Direct transaction?
· Arien Malec – No, the HISP and provider role may be combined, though it’s desirable for them to be separable
· Dixie Baker – Our assessment did not look at just HISP-HISP
· Arien Malec – The abstract model is source-destination with multiple potential HISPs. Dixie’s interpretation is correct.
· John Halamka– A provider-provider exchange may not involve a HISP in the middle
o As long as we can be assured of security, the REST/SMTP combination seems like it will be simple to use and implement
Arien Malec
· We can use today’s meeting notes as written commentary, but does Dixie also have a written recommendation to provide?
· Dixie Baker – Yes, we’ll clean up our evaluation and provide to Arien
Arien Malec
· Each implementation team can also provide additional considerations for the HTISC to work from
John Halamka
· Our evaluation was based on multiple constraints: NHIN Direct consensus requirements, the simplicity principle, and also MU transactions in absence of a policy framework
Arien Malec
· We’ll provide meeting notes at the end of the day today and provide any written information from Dixie at the face-to-face
Eric Heflin
· Noticed that the review criteria on wiki seem inconsistent with the discussion today
John Halamka
· To put this review in context, this is a recommendation for a prudent next step for a pilot
· Arien Malec – That’s a fair statement.
Notes from HITSC Review of Concrete Implementations: Part II
Date: June 9, 2010
Time: 3pm-4pm
Attendees: Ashley Corbin, Carol Diamond, Dixie Baker, John Halamka, Arien Malec, Ravi Madduri, Lin Wan, David McCallie, Vassil Peytchev, Jason Colquitt, Nageshwara Bashyam, Karen Witting, Eric Heflin, Mark Stine, Sean Nolan, Konda Mullapudi, Jackie Key, Ioana Singureanu, Mark Gingrich, Brett Peterson, Didi Davis, Laurie Tull, Peter DeVault, Janet Campbell, Justin Stauffer, Thanos Tsiolis, Christopher Moyer, Jack Ousey, Martin Prahl, Paul Egerman, Lee Jones, Joel Ryba, Parag More, Doug (CMS)
Agenda
- HITSC reviewer questions and recommendation
Materials:
HITSC Review Results:
Notes
HITSC reviewers were provided with the following review materials in advance of the meeting: http://nhindirect.org/HITSC+Review
Arien Malec
· Both the HIT Standards Committee (HITSC) and HIT Policy Committee’s (HITPC) Privacy and Security tiger team are undertaking parallel processes that will incorporate feedback from this HITSC review group
· The Implementation Group will recommend a set of specifications for NHIN Direct to move forward with as these processes occur in parallel
o Note that this decision may not meet the eventual requirements defined by the HITSC and HITPC
o These committees will inform us of any gaps between the NHIN Direct specifications and the HITSC and HITPC requirements and we’ll work to address these gaps
· NHIN Direct is aiming for a robust set of nationwide capabilities in support of MU and other improved healthcare outcomes identified by ARRA
o Feedback from HITSC and HITPC will help us to deploy these capabilities
· We realize that from a timing perspective, the feedback process is a bit backward
Paul Egerman
· The process is not ideal, but it’s interesting to do policy and technology in parallel so that the policy can realistically reflect what technology can accomplish
· We’ll try to harmonize the work of NHIN Direct with the policy work
John Halamka
· We recognize that policy and technology are being done in parallel
· If we had more time, we might have tried to do policy ahead of time
· For her evaluation of the four options, Dixie has compared the four implementations against the following:
o Consensus requirements for NHIN Direct
o Policy requirements
· We wanted to first ensure that the consensus requirements are met by implementations, then once we’d understood the implementations’ strengths and weaknesses against these requirements, identify the simplest option
Dixie Baker
· While our assessment was based on the NHIN Direct consensus requirements, we recognize that these requirements were established in absence of a policy framework
· Our assessment was done assuming that the consensus requirements could change as policies are defined
· For our security assessment, simplicity is not an “also”, it’s essential. Complexity breeds vulnerabilities.
Compliance with Consensus Requirements:
· We first looked at the four implementations with the consensus requirements as a yardstick
· We did not feel that XMPP meets the requirements
o XMPP implementation does not use x509 certs for authentication, but uses SASL
o Don’t believe XMPP should be further considered
· We thought that the remaining three implementations are compliant with the consensus requirements
Simplicity:
· IHE exposes PHI and manipulates PHI unnecessarily in order to generate metadata for sending documents
· While metadata adds value, it also presents unnecessary risks
o Confidentiality – PHI is exposed more than necessary
o Integrity – PHI is manipulated more than necessary
· IHE solution is overly complex, doesn’t meet simplicity requirement
· Relies on XDR and XDS, which were designed for the exchange of patient specific information
o Many MU reporting scenarios are not patient specific
· Both REST and SMTP meet the consensus requirements and both are simple.
o We’d like to see these two solutions coexist
· Concerned that SMTP leaves too much enforcement at the discretion of the user
· Would rather see a NHIN account that is accessible through the HISP, allowing the HISP to manage enforcement and not leaving this to the client
· Would like to see both REST and SMTP taken forward as an integrated solution
John Halamka
· We made our evaluation from a policy and requirements driven perspective
· We first looked whether each implementation met the consensus requirements (XMPP did not), then looked at simplicity (IHE was not simple)
· The idea of a RESTful implementation where SMTP could be offered by a HISP, not having just SMTP at the edge, seems like the best combination
Dixie Baker
· No implementation should move forward without the policy framework and validated security requirements in place
· The tiger team is on an aggressive schedule that shouldn’t delay the implementation
John Halamka
· IHE has a valuable place, but in the case of the simplicity required for edge-edge transmission, it did not seem to fit
· REST with a SMTP offering from the HISP seemed to offer the best balance
Carol Diamond
· From the policy side, Dixie got it right
· The notion of having a policy framework creates expectations that the disclosure of information should be minimized
David McCallie
· Should we debate now and respond to the HITSC evaluation?
Arien Malec
· Keep in mind that this is a preliminary recommendation, not a final recommendation or decision
· Note that the parallel HITSC and HITPC processes may introduce new requirements or clarity
Carol Diamond
· I think a Q&A session would be helpful
Responses from Concrete Implementation Teams to HITSC Review
Nageshwara Bashyam
· Looking at the statement that SASL doesn’t conform with x509 requirements
· SASL is an authentication mechanism
· XMPP approach uses the SASL external mechanism, which supports x509 certificates
· Maybe I didn’t clarify this well in the XMPP capability worksheet
Dixie Baker
· If SASL is a fundamentally a challenge response protocol, how are x509 certs used?
· Nageshwara Bashyam - Challenge response is one of the options
o You can have a client certificate and a server certificate
· Arien Malec – The SASL external specification says that we’ve already handled authentication at a lower level of the stack (via TLS)
Peter DeVault
· Concerned that the review was done using the capability worksheets as they were last week. The teams only first presented their work in a complete, unified way yesterday.
· Yesterday the IHE team showed that REST and SMTP can be used on the edge, with XDR as a backbone. We demonstrated that having XDR as a backbone offers several advantages, including interoperability with NHIN Exchange.
· The only place PHI-containing metadata might be visible would be at a trusted intermediary, such as a HISP
Karen Witting
· There are many ways PHI could be protected
· Metadata is important. The IHE team feels that the other implementations have too little metadata, which will be problematic
· Our model allows us to identify a minimal metadata set which could be further constrained based on policy requirements
· Confused by the mention of patient-specific information, wasn’t every NHIN Direct use case about patient-specific transactions
· John Halamka - When we look at MU data exchanges, there are transactions where packages or summary-level data are pushed
· Arien Malec - The NHIN Direct user stories as written do include quality reporting, but these were given lower priority relative other user stories
· John Halamka - GIPSE packages or PQRI packages wouldn’t necessarily be patient specific
o How do you generically transport these packages securely from a small guy?
· Doug from CMS -We’re talking about NHIN Direct. CMS will not receive information from NHIN Direct but from NHIN Exchange.
· John Halamka – A provider would use the simple NHIN Direct protocol to send data to an intermediary and then the intermediary could route this appropriately
· Doug from CMS –An EHR vendor could also perform this function
· Vassil Peytchev - What you have described validates the point that transformations from NHIN Direct to NHIN Exchange will have to happen. This extra step might comprise security.
· Doug from CMS –There were no certificates in these examples. With NHIN Exchange there are certificates and they are encrypted.
Dixie Baker
· The idea is that NHIN Direct is supposed to be the most simple transport from A-B, with value-added services potentially provided in-between, but NHIN Direct wouldn’t be concerned with the provision of these services
· Doug from CMS - Not sure how NHIN Direct plays into HCR and MU
John Halamka
· I see NHIN Direct as a set of tools that could be made available to small providers as part of their arsenal to perform exchanges for MU
· We are on a timeframe to get running code available in time for providers to use for MU
· Arien Malec - The intent of NHIN Direct is to provide an electronic means for providers to achieve this
John Halamka
· We should think about how we can be as thin as possible on the edges and also ensure security
Lee Jones
· What is meant by simple?
· Dixie Baker – Even just listing the number of functions that a HISP provides under IHE, IHE provides many more functions than the other options. Given that the function we’re supposed to provide is to get a document from A-B securely, anything beyond this is more than simple
· John Halamka – If I ask a programmer to complete a RESTful implementation of code, it takes less than a day. If I ask someone to complete a SOAP implementation, it takes longer. RESTful implementations are easier for programmers to program and debug.
· Paul Egerman– This definition of simple relates to technical simplicity, as opposed to simplicity from the user’s perspective
· Dixie Baker – What you really want is for the behavior exposed to the end user to be simple for them.
o Something can be complex under the covers but simple to the user.
· Lee Jones – Complexity to the user is the same for all of these implementations.
o The user interface (UI) will mask this for all users.
o We have to account for what different vendors who are providing these interfaces have already and integration to the rest of their healthcare offerings. Even for a simple, no healthcare technology deployed at the edge scenario, there’s still work to be done.
· Peter DeVault – Simplicity has been spoken about in a variety of ways. One is for the programmer, one is in terms of moving parts/vulnerability, and one is simplicity from the provider’s point of view
o It’s true that all transport protocols are equally simple to use with a client
o The user stories we’re addressing aren’t only for provider-provider, but for healthcare organizations – health care organizations in general. In this case, NHIN Direct must be simple for a single provider and an organization using an EHR.
o This is why it’s important to be able to vary the edge protocol and keep a common backbone. Simplicity isn’t always just technology.
· John Halamka – When we conducted our review, we may have each had a different internal definition of simplicity.
o We assumed the user interfaces for the doctor would look similar
o Many stakeholders (EHR vendors, aggregators, decision support, etc) will all be trying to do simple point-point push, so how do we identify the simplest implementation.
o IHE is very useful for pull transactions with government players
o We looked for the options with the fewest moving parts, fewest functions, and ease of implementation
· Dixie Baker – Also, we cared about the fewest user-made decisions that could impact security
o This was the concern with SMTP
o You want the easiest thing for the user to do to also be safest thing
Eric Heflin
· Important for us to focus on the decision before us for this week
· The decision before us is only to decide on the HISP-HISP backbone protocol, not the edge protocols. There have been comments regarding end user issues, but simplicity for the end user is not relevant to the backbone. Concerned that the backbone is being oversimplified, it’s legitimate for the backbone to be more sophisticated. If we constrain the functionality of the backbone, it can never be added back in.
John Halamka
· If a provider knows the IP address of another provider, is a HISP a necessary part of a NHIN Direct transaction?
· Arien Malec – No, the HISP and provider role may be combined, though it’s desirable for them to be separable
· Dixie Baker – Our assessment did not look at just HISP-HISP
· Arien Malec – The abstract model is source-destination with multiple potential HISPs. Dixie’s interpretation is correct.
· John Halamka– A provider-provider exchange may not involve a HISP in the middle
o As long as we can be assured of security, the REST/SMTP combination seems like it will be simple to use and implement
Arien Malec
· We can use today’s meeting notes as written commentary, but does Dixie also have a written recommendation to provide?
· Dixie Baker – Yes, we’ll clean up our evaluation and provide to Arien
Arien Malec
· Each implementation team can also provide additional considerations for the HTISC to work from
John Halamka
· Our evaluation was based on multiple constraints: NHIN Direct consensus requirements, the simplicity principle, and also MU transactions in absence of a policy framework
Arien Malec
· We’ll provide meeting notes at the end of the day today and provide any written information from Dixie at the face-to-face
Eric Heflin
· Noticed that the review criteria on wiki seem inconsistent with the discussion today
John Halamka
· To put this review in context, this is a recommendation for a prudent next step for a pilot
· Arien Malec – That’s a fair statement.