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