Individual Involvement Meeting 2010-04-26

Notes from 'Individual Involvement' Workgroup
Status of Notes: DRAFT
Date: April 29, 2010
Time: 1pm-2pm
Attendees: Honora Burnett, Arien Malec, Richard Elmore, John George
David Kibbe, Janet Campbell, John Moehrke, Paul Saxman, Sean Nolan, Umesh Madan, Aditya Naik, Theresa Hancock

Action for This Week

#	Date	Action	Status	Owner	Due Date
14	4/28/10	Create a statement about the importance of patient to provider communication, its technical implementation, and the issues it raises.	Open	Janet Campbell and John Moehrke	5/6/10
15	4/28/10	Provide recommendation for patient-provider communication in addition to Security & Trust proposal	Open	Arien	5/6/10

Action from Last Week

#	Date	Action	Status	Owner	Due Date
13	4/22/10	Describe business problem in technology neutral terms	Completed	Arien	4/29/10

Notes
· Linkages from other work groups

· Actions: Finalize Patient Sends Message to a Provider User Story

Agree on this //Patient Sends Message to Provider// story and then ask the S&T group to work on this on our behalf
· Who should be providing the guidance for governance/technology for this?
o Complicated topic
o Consensus statement says this is the a policy issue – if you take this on, you are taking on the policy issues bc they are non-trivial and we are staying out of that business
· Because it isn’t the patient sending this
· Definition of white list: opening up a trust relationship that exists between patients and providers, motivated by an identity proofing issue
o We need to talk to abstract model or content packaging group
· Consider this next time: notion of subtypes of rejection
· White list is the typical method for the patient side

· Difference between specification must support, and implementation policies must support the requirements:
o Universal transport mechanism to security route a mechanism from one to another
o A mechanism for two organizations to decide whether they trust each other
o Any other mechanisms are outside the technology space

Review HITPC Meeting on Patient/Consumer Engagement: //April 20 testimony//
· We need to make sure this is getting attention and priority
· Should our specifications support this type of user story? Should/Must?
· Comment from John George
o Let’s think about the ramifications/implications
o Aren’t some of the same rules applicable across the board?
o Technology component to this
· Comment from Janet Campbell
o Sticking to “reasonable”
o Continue to be a should
· Comment from Paul Saxman
o If we are stuck with an asymmetric trust model it should be proposed
· Comment from Sean Nolan
o Special cases from patients
o Raise it to a must
o Depends on what we mean by must
o Asymmetry holds broadly
· Comment from Arien Malec
o Concerned that this is a must user story commits us to a policy
o We can address these, but maybe we won’t address them by September
o Keep must list as minimal as possible
· Is there a misunderstanding of Must/should
o Must: written specification document must be able to accommodate the user story case
§ Organizations will deploy subsets of the stories that are relevant to their business needs
· John Moehrke will propose a new Must/Should definition that makes the difference between policy must/should – combine with consensus statement that packages up this discussion and says “if you want to do this, here is how you should be thinking about it!”
· By next week we put together a consensus statement that says
o We think this is an important area for the following regions, feasible according to technology and here is how you do it Janet Campbell will do the first draft and then John Moehrke will review
o Two columns – technology/policy

Conversations for next time:
· Decisions - Recap
o Proposed Guidance to Packaging Work Group
§ Given the workflow conditions, there may be a cover letter. There should also be the ability to annotate specific files.
o Proposed Guidance to the Security & Trust Work Group
§ Asymmetric trust problem
o Confirmed Individual Involvement User Stories
§ Provider sends patient health information to the patient
§ Hospital sends patient health information to the patient
§ Provider sends a clinical summary of an office visit to the patient
§ Hospital sends a clinical summary at discharge to the patient
§ Provider sends a reminder for preventive or follow-up care to the patient
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.
    • 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”