Individual Involvement Meeting 2010-04-08

Status of Notes: DRAFT
Date: April 8, 2010
Time: 1pm-2pm Eastern
Attendees: Honora Burnett, Arien Malec, Richard Ellmore, Aditya Naik, David Kibbe, Didi Davis, Garrett Dawkins, Janet Campbell, John Moehrke, Rob Wilmot, Sean Nolan, Lois Hooper , Paul Saxman

Actions

#	Date	Action	Status	Owner	Due Date
2	4/8/10	Provide Details on the Wiki around a Framing Issue for next week: Read/Receipt or Receipt of safe transport (Janet Campbell)	Open	Janet Campbell	4/15/10
3	4/8/10	Ask around and get advice from NIST on whether it is required to provide access of if the patient received the message(Arien)	Open	Arien Malec	4/15/10
4	4/8/10	Provide Details on the Wiki around a Framing Issue for next week: Trust mechanism needs to individually asset two different transactions – Me sending to you, and you sending back to me. (i.e. Provider can send to patient, but patient can’t send back to provider) (John Moehrke)	Open	John Moehrke	4/15/10
5	4/8/10	Provide proposal from the Individual Involvement WG that the core 2011 Individual Involvement Stories be elevated to a “Must” (Arien)	Open	Arien Malec	4/15/10
6	4/8/10	Add a story for 2013 patient to doctor formatting (Arien)	Open	Arien Malec	4/15/10
7	4/8/10	Provide a write up our conversation about multipart messages and formalize team agreement (Rich Elmore)	Open	Rich Elmore	4/15/10
8	4/8/10	Provide clarification of assumption on the Wiki: NHIN Direct is a specified way, but not the only specified way to do this. This is also in the Abstract Model. (John Moehrke)	Open	John Moehrke	4/15/10
9	4/8/10	Provide Details on the Wiki around a Framing Issue for next week: define trust framework (ideas of mutual trust and symmetric trust) on the Wiki (Sean Nolan)	Open	Sean Nolan	4/15/10

Decisions

#	Date	Decision

Notes

Agenda

1. Review of actions from previous meeting
2. Discussion based on Issue Framing
3. Review of actions and decisions

Issue Framing

• Meaningful Use 2011 – Individual Involvement objectives:

• • Send reminders to patients for follow-up and preventive care

• • Provide patients with access to their health information within 96 hours (results, problems, meds, etc.)

• • Provide clinical summaries for patients after each office visit

• • Meet threshold for EP’s that 10% of patients are accessing their health information electronically

• • Others?

• User story review

• • Review Individual Involvement – related user stories
  • ID explicit tie-ins to user stories for NPRM / IFR criteria
• “Meeting patients where they are”: a proposal

• • Each Individual may have multiple addresses (multiple PHR’s, multiple e-mails, etc.)
  • 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 is responsible to send PHI only to systems (like PHR’s) which have authentication/security for Individuals (and optionally may notify the Individual of the update via public email – “where they are”).

Discussion

Review of linkages from other workgroups

No items relating to individual involvement
 
 
 

Meaningful Use 2011 – Individual Involvement objectives:

• Send reminders to patients for follow-up and preventive care
  • Not familiar with standards that allow us to have this
  • Allow for the multiplicity or formats
  • We are not mandating these things, but simply saying that we need to do whatever we can within NHIN Direct to enable these as best we can
  • Nothing in our model that excludes that

• Sean’s point: Do we want to be looking at this as bi-directional?
  • Don’t need to model multi-lateral
  • Difference between trust in the two directions
  • Big difference in having the ability to have a doc to send to a patient and having a doc just accepting from a patient – different and scary

• Provide patients with access to their health information within 96 hours (results, problems, meds, etc.)

• Provide clinical summaries for patients after each office visit

• Meet threshold for EP’s that 10% of patients are accessing their health information electronically

• Others?

• Clarification from David Kibbe
  • Markel’s foundations comments from NPRM what it meant to give patients their summaries
  • Issue was not only that patients should be able to view and download their summaries in one of the IFR approved standards – should we include this?

• Arien Malec
  • As long as the mechanism we propose is able to send information in many formats (CCD or CCR), we are in compliance with NPRM and IFR

• Comment from Janet Campbell
  • Meeting the threshold of 10% of patients
  • Framing Issue: Read/Receipt or Receipt of safe transport (Janet Campbell)

• Comment from Lois Hooper
  • Within 96 hours of what?
  • Ask around and get advice from NIST on whether it is required to provide access of if the patient received the message(Arien)

• Update from Arien about User Stories
  • Arien did a complete revision of the User Stories
  • Story for each meaningful use criterion
  • The actual stories are basically “providers send stuff to the patient”
  • Data exchanged, one thing that is worth calling out from the content packaging side:
    • If you send multiple things in one package, do you assume they are all related
    • Provided need to provide textual context for the patient “dear patient …”
    • Just sending CCR wouldn’t be a patient friendly thing to do
    • Raise the issue of how you interpret content being sent to patient
    • When writing the story, Arien felt the need to provide textual commentary to the data
    • Think that there is a user need to provide context or commentary to the information
    • Not debating the point that you can take CCR or CCD and make it patient friendly
    • Need to provide context/commentary around it

• Comment from David Kibbe
  • What is a user friendly content and what is not
  • Careful about assuming with that is or not
  • Need to anticipate innovation and if our data types become useful
  • Innovation would include easier readers and display it to make it user friendly
  • Shouldn’t think too literally about when the message gets to the patient, because when it gets there it will be able to be read
  • We have to be humble about the tools or lack of tools that makes something user friendly
  • Clarified by what we mean by “user friendly”

• Comment from Janet Campbell
  • How will information be delivered?
  • Conversation in the content packaging group

• Comment from John Moehrke
  • What are the requirements for NHIN Direct?
  • Have to be able to support rich documents and plural documents
  • Consistent with Content Packaging Groups
  • Framing Issue: Trust mechanism needs to individually asset two different transactions – Me sending to you, and you sending back to me. (i.e. Provider can send to patient, but patient can’t send back to provider) (John Moehrke)

• Comments from Rob Wilmot
  • Need to have relationships amongst documents

• Comments from Rob Wilmot
  • Multipart message format, mail providers have solved this

• Action Item: Proposal from the Individual Involvement WG that the core 2011 Individual Involvement Stories be elevated to a “Must” (Arien)
• Add a story for 2013 patient to doctor formatting (Arien)

• Comment from Paul Saxman
  • Content packaging needs
  • What do we mean by patient information

• Comment from Aditya Naik
  • If the content needs to be approved format, we have to have a frame that it has to be in a recognized format
  • If there is someone to recognize this, then the recipient has to have the architecture
  • We could make recommendations to a PHR or EHR System
  • Arien: minimal criteria are to be able to attach a CCD/CCR and expose a viewer for the patient

• Comment from Arien
  • If you send a multipart MIME message with a text and CCD/CCR section, does the receiver of that message assume that those two parts are part of the same message?
  • Rules that say “When I get a message that has CCR I will assume the text block is contextual information and I will render it that way”
  • Another point of view: “don’t limit ourselves to making an assumption that all parts of a message are related to one patient”
  • XDR makes assumption that all the stuff it is sending is related to the same patient – related to the packaging WG
  • Goes back to David McCallie's point that different channels have different expectations

• Comment from Rich Elmore
  • Do we need to do any more verification as they relate to individual involvement
  • Look to this group to review User Stories and suggest more
  • Action Item: Provide a write up our conversation about multipart messages and formalize team agreement (Rich Elmore)

• “Meeting patients where they are”: a proposal
  • Each Individual may have multiple addresses (multiple PHR’s, multiple e-mails, etc.)
  • 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 is responsible to send PHI only to systems (like PHR’s) which have authentication/security for Individuals (and optionally may notify the Individual of the update via public email – “where they are”)

• Comment from David Kibbe
  • One person has the information in their hands; they can do anything they want with it
  • Careful that they don’t over determine that

• Comment from Garrett Dawkins
  • Is there a need to specify some expectations of a PHR
  • Out of scope

• Comment from Janet Campbell
  • Transport level CC hasn’t been uncovered yet
  • Abstract Model WG – any destination will be serviced by a destination HSP (Health Information Service Provider) Routing point in the middle between source/destination
  • Functional bundle of capabilities that know how to take a message addressed to someone and know how to route it to a trustworthy endpoint

• Comment from John Moehrke
  • Authentication and security for individuals is out of scope at the transaction level (not at the policy level) – agree
  • Clear that these are not requirements we’re placing on organizations
  • Capabilities that are required of the NHIN Direct Solution if that is chosen to be used
  • Clarify of assumption: NHIN Direct is a specified way, but not the only specified way to do this. This is also in the Abstract Model. (John Moehrke)
  • Senders responsibility to ensure they are in conformance with legal/regulatory equipments

• Comment from Sean Nolan
  • If patient receives notification, NEW USER STORY

• Sean Nolan’s question as an urgent trust issue
  • All of our policy notions have been based on our notions of mutual trust
  • Introduced a requirement for asymmetric trust
  • Sean believes this is covered with the currently proposed trust model
  • Framing Issue: define trust framework (ideas of mutual trust and symmetric trust) on the Wiki (Sean Nolan)

Wrap Up