Individual Involvement Meeting 2010-04-22
Jump to navigation
Jump to search
Notes from Individual Involvement Workgroup
Status of Notes: DRAFT
Date: April 22, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Didi Davis, Janet Campbell, Richard Elmore, Rob Wilmot, John George, Fred Trotter, Sean Nolan, David Kibbe, Eric Heflin, Garrett Dawkins, Paul Saxman, Keith Boone, John Moehrke & Arien Malec
Action from This Week
o Proposed Guidance to Security & Trust workgroup: Asymmetric Trust (Sean)
o Proposed Guidance to Packaging workgroup: Descriptions of content (including multipart) (Arien)
Discussion
· Description from Sean
· Three key bullets
o 1) Relationship between members and organization that they belong to is different for patient information than for provider organization
o 2) Generally acceptable for provider organizations to have crosswire trust with all their members, but not exactly the same
o 3) Trust between provider and a patient may not be mutual
o [1]
· Any other class of user that we’d want to consider – what about a “break the glass” case?
· Could the HISP take on the heavy lifting?
§ Implications: EHR will have to take on some of the heavy lifting as well
· Comment from Didi Davis
o HISP should do the heavy lifting
o Have to make sure those are connected to facilitate provider to patient and patient back to provider access
· Comment from Janet Campbell
o Adding concept of “trust/role” to the header is worrisome
o Anyone can push to anyone
· Comment from Rob Wilmot
o Asymmetric trust or application work
· Comment from Fred Trotter
o Do we have a real word trust relationship?
o What levels take care of what
o Been talking through the trust assertion and you trust me because you trust the policies I follow
§ Identity assurance etc …
§ Routing perspective, holds for patient side of things
§ Do we want to hold role information in package of routing metadata?
· Comment from David Kibbe
o Old days, had the opportunity to establish roles
o Roles were policies – all of this was application level stuff
o Health Service Provider shouldn’t have to deal with this
o Metadata to describe roles is cultural and needs to be left to the
o Keep the heavy lifting to the HISP
· Comment from Eric Heflin
o Associations and credentials and roles and user provisions and processes that have been solved, we should look into those who have already done this work, to see if we can leverage it
o NIST Special publication 800-63 addresses assurance levels lowest level of sharing a password to high level cryptography
§ Explicitly government use and NHIN Workgroup looked at these levels of assurance that these don’t really apply to non-government assurances
§ One approach is open ID, and other one is an affidavit in front of a notary public
o SAML is intended to address these issues
o Robust NHIN WG is already working on this and has delegated explicitly the user experience to someone
· Comment from Arien
o Assumed provider/provider trust model and convinced ourselves that we could do this
o Introducing individual introduces the idea of asymmetric trust
o Sean’s model moves a lot of the heavy lifting from the HISP to the EHR
o Not a solution, but play through the implications
o Sean has outlined scenarios that highlight the scenarios for mismatch from our previous discussions
o Make sure that the protocol has the raw materials on the wire to implement these decisions
o Where did we start?
§ Even if I trust that the organization that I’m dealing with has properly managed the identity of the patient
§ There are plenty of valid reasons why a provider wouldn’t want to receive an inbound message
· Not my patient
· Don’t want to do inbound patient communication
· Don’t want to talk to this patient
o Concern for S&T WG is that we want not just S&T, but scalable S&T
o Arien will describe business problem in technology neutral terms to the S&T WG
§ Plausible to imagine that if I know that the user (patient) it purports to be
§ If a provider sends a message, going to accept it to look at contents whereas if a patient sends a message, even if the doc knows who it is, might not automatically want to accept
§ Delegate “how do I know” HISP
· Comment from Rich Elmore
o These have been done before – look at SPAM filters
o Tight integration and deep workflows is key
· Comment from John Moehrke
o Much of what is being commented on here exhibits a lack of trust in the other workgroups
o Content providence and what transport did I get it by way of?
o Content needs to explain, who is the author and where does the data come from
§ Application/content problem?
§ Packaging problem?
o Transitive trust – Org A trusts Org B who trusts Org C, therefore Org A trusts Org C
o Document based digital signatures
· We should put forth the requirements and delegate this to the Security & Trust WG
· Written more from the perspective of the Individual Involvement Workgroup
· Arien will describe the trust problem from a patient and physician in the language of the individual involvement
· Move to next week
o HITPC Meeting on Patient/Consumer Engagement: April 20 testimony
o Reopen discussion – one of the most important things is to connect patients with providers
o Reconsider should with patients talking to providers
o Deliverable: don’t have service descriptions, have set of assumptions for directions to other workgroups
Status of Notes: DRAFT
Date: April 22, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Didi Davis, Janet Campbell, Richard Elmore, Rob Wilmot, John George, Fred Trotter, Sean Nolan, David Kibbe, Eric Heflin, Garrett Dawkins, Paul Saxman, Keith Boone, John Moehrke & Arien Malec
Action from This Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 13 |
4/22/10 |
Describe business problem in technology neutral terms |
Completed |
Arien |
4/29/10 |
Actions from Last Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 10 |
4/15/10 |
Summarized for consensus to be able to pass on for the packaging group: given the workflow conditions, there would be cover letter but should also be able to annotate specific files as well |
Completed |
Arien |
4/22/10 |
| 11 |
4/15/10 |
Wrote up a description of the asymmetric trust problem to pass onto the Security & Trust to figure out an elegant solution |
Completed |
Sean |
4/22/10 |
| 12 |
4/15/10 |
Next week we will agree on this Patient Sends Message to Provider story and then ask the S&T group to work on this on our behalf: http://nhindirect.org/A+patient+sends+a+message+to+the+provider |
Open |
All |
4/22/10 |
Agenda & Framing
· Linkages from other work groups (Arien)
· Decisions - Recap (Rich)
o Individual involvement scope
§ 2011 Stage 1 MU – Must
§ Provider sends a reminder, health information, clinical summary or discharge summary to an Individual
§ 2013 Stage 2 MU – Should
§ Individual sends message to a provider
o Meeting individuals “where they are” – assumptions
§ Each Individual may have multiple addresses (e.g., for multiple PHR’s, multiple e-mails). Each address has its own separate transmission.
o Outside of NHIN Direct:
- Provider verifies identity and consent before linking to an Individual’s address
- Provider makes the decision that it’s appropriate to provide information to this address
- Provider verifies that PHI is sent only to addresses with adequate authentication/security/logging
- These target addresses may optionally provide notification services to the Individual of the update via public email – “where they are”
o Proposed Guidance to Security & Trust workgroup: Asymmetric Trust (Sean)
o Proposed Guidance to Packaging workgroup: Descriptions of content (including multipart) (Arien)
Discussion
· Description from Sean
· Three key bullets
o 1) Relationship between members and organization that they belong to is different for patient information than for provider organization
o 2) Generally acceptable for provider organizations to have crosswire trust with all their members, but not exactly the same
o 3) Trust between provider and a patient may not be mutual
o [1]
· Any other class of user that we’d want to consider – what about a “break the glass” case?
· Could the HISP take on the heavy lifting?
§ Implications: EHR will have to take on some of the heavy lifting as well
· Comment from Didi Davis
o HISP should do the heavy lifting
o Have to make sure those are connected to facilitate provider to patient and patient back to provider access
· Comment from Janet Campbell
o Adding concept of “trust/role” to the header is worrisome
o Anyone can push to anyone
· Comment from Rob Wilmot
o Asymmetric trust or application work
· Comment from Fred Trotter
o Do we have a real word trust relationship?
o What levels take care of what
o Been talking through the trust assertion and you trust me because you trust the policies I follow
§ Identity assurance etc …
§ Routing perspective, holds for patient side of things
§ Do we want to hold role information in package of routing metadata?
· Comment from David Kibbe
o Old days, had the opportunity to establish roles
o Roles were policies – all of this was application level stuff
o Health Service Provider shouldn’t have to deal with this
o Metadata to describe roles is cultural and needs to be left to the
o Keep the heavy lifting to the HISP
· Comment from Eric Heflin
o Associations and credentials and roles and user provisions and processes that have been solved, we should look into those who have already done this work, to see if we can leverage it
o NIST Special publication 800-63 addresses assurance levels lowest level of sharing a password to high level cryptography
§ Explicitly government use and NHIN Workgroup looked at these levels of assurance that these don’t really apply to non-government assurances
§ One approach is open ID, and other one is an affidavit in front of a notary public
o SAML is intended to address these issues
o Robust NHIN WG is already working on this and has delegated explicitly the user experience to someone
· Comment from Arien
o Assumed provider/provider trust model and convinced ourselves that we could do this
o Introducing individual introduces the idea of asymmetric trust
o Sean’s model moves a lot of the heavy lifting from the HISP to the EHR
o Not a solution, but play through the implications
o Sean has outlined scenarios that highlight the scenarios for mismatch from our previous discussions
o Make sure that the protocol has the raw materials on the wire to implement these decisions
o Where did we start?
§ Even if I trust that the organization that I’m dealing with has properly managed the identity of the patient
§ There are plenty of valid reasons why a provider wouldn’t want to receive an inbound message
· Not my patient
· Don’t want to do inbound patient communication
· Don’t want to talk to this patient
o Concern for S&T WG is that we want not just S&T, but scalable S&T
o Arien will describe business problem in technology neutral terms to the S&T WG
§ Plausible to imagine that if I know that the user (patient) it purports to be
§ If a provider sends a message, going to accept it to look at contents whereas if a patient sends a message, even if the doc knows who it is, might not automatically want to accept
§ Delegate “how do I know” HISP
· Comment from Rich Elmore
o These have been done before – look at SPAM filters
o Tight integration and deep workflows is key
· Comment from John Moehrke
o Much of what is being commented on here exhibits a lack of trust in the other workgroups
o Content providence and what transport did I get it by way of?
o Content needs to explain, who is the author and where does the data come from
§ Application/content problem?
§ Packaging problem?
o Transitive trust – Org A trusts Org B who trusts Org C, therefore Org A trusts Org C
o Document based digital signatures
· We should put forth the requirements and delegate this to the Security & Trust WG
· Written more from the perspective of the Individual Involvement Workgroup
· Arien will describe the trust problem from a patient and physician in the language of the individual involvement
· Move to next week
o HITPC Meeting on Patient/Consumer Engagement: April 20 testimony
o Reopen discussion – one of the most important things is to connect patients with providers
o Reconsider should with patients talking to providers
o Deliverable: don’t have service descriptions, have set of assumptions for directions to other workgroups