Automate Blue Button Initiative Push Workgroup Meeting November 5, 2012

Meeting Etiquette Remember: If you are not speaking, please keep your phone on mute Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call o Hold = Elevator Music = frustrated speakers and participants This meeting is being recorded o Another reason to keep your phone on mute when not speaking Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know. o Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute All Panelists 2

Agenda TopicTime Allotted Welcome and Announcements5 minutes Status, Deliverables, Dashboard5 minutes Draft Implementation Guide – Feedback45 minutes Next Steps / Reminders5 minutes 3

Announcements and Reminders 4 Meeting Reminders – Push Workgroup Meetings are Mondays from 2:00 – 3:00 pm Eastern. – The next Community Meeting will be held as needed. – Meeting information is on the Automate Blue Button Wiki Page: Community Homework – Provide comments and feedback on the Push Implementation Guidance Documents: Feedback

Pre- Discovery Discovery Reference Implementations  Agreed and voted on charter, including  Scope  Timeline  Deliverables  Identified priority implementation options:  Transmit requirement of MU Stage 2 (from V/D/T requirement) + automation  + file encryption also discussed as option for PUSH  Wrote draft use case for two V/D/T + automation  Write draft use case for (and/or Payer) option  Identified issues related to V/D/T + automation  Write policy FAQ document to support PUSH options  Write draft implementation guide for V/D/T + automation  Write draft implementation guide for  Identify 1-2 V/D/T implementations that can serve as reference implementations for our group  Identify 1-2 vendors / data holders willing to work on Automated Push reference implementations Implementation Guidance Implementations  Refine use cases based on reference implementations  Refine implementation guide based on reference implementations  3-6 full implementations that reflect implementation guidance PUSH Current Status 5

PUSH Current Deliverables Implementation guideUse Case Issue List Push Workgroup 6 entation+Guide_Direct_ v1.docx file/view/ABBI+Push+Implem entation+Outlines docx

WG Launch (09/17) Nov-12 Discovery S&I Framework Lifecycle Sep-12Mar-13 Pilot & Implementation Guidance Implementation Oct-12 Dec-12 Jan-13Feb-13 Finalize Implementation Guidance for Direct Use Case 1 Definition Physician’s Office) Use Case 2 Definition (DIRECT via Patient Portal) Use Case 3 Definition ( ) UC3 Implementation Guidance for Full implementations with providers / Payers Timeline Outstanding Issues Pilots Identified & On Track Next StepsStatus PUSH Dashboard Draft Implemen tation Guidance Reference Implementations using Direct Reference Implementations using Push Workgroup 7  Write policy FAQ document to support PUSH options  Write draft implementation guide for V/D/T + automation  Write draft implementation guide for  Identify V/D/T implementations that can serve as reference implementations for our group  Identify vendors / dataholders willing to work on Automated Push reference implementations

Push Implementation Outlines ation+Outline+Comments+and+Feedback ation+Outline+Comments+and+Feedback

Implementation Guide – For Example… 9

Community Feedback and Comments Thomson Kuhn IG - Technical Guidance – B. Handling a Patient’s Request for Transmit 45 C.F.R. § requires more than these three elements when the authorization is for a non-HIPAA covered third party. (c) Implementation specifications: Core elements and requirements—(1) Core elements. A valid authorization under this section must contain at least the following elements: (i) A description of the information to be used or disclosed that identifies the information in a specific and meaningful fashion. (ii) The name or other specific identification of the person(s), or class of persons, authorized to make the requested use or disclosure. (iii) The name or other specific identification of the person(s), or class of persons, to whom the covered entity may make the requested use or disclosure. (iv) A description of each purpose of the requested use or disclosure. The statement ‘‘at the request of the individual’’ is a sufficient description of the purpose when an individual initiates the authorization and does not, or elects not to, provide a statement of the purpose. (v) An expiration date or an expiration event that relates to the individual or the purpose of the use or disclosure. The statement ‘‘end of the research study,’’ ‘‘none,’’ or similar language is sufficient if the authorization is for a use or disclosure of protected health information for research, including for the creation and maintenance of a research database or research repository. (vi) Signature of the individual and date. If the authorization is signed by a personal representative of the individual, a description of such representative’s authority to act for the individual must also be provided. Further required statements are listed in the regulation.

Community Feedback and Comments Greg Meyer – In the implementation guide, I would like more clarification on the following sentence: "Your system can communicate the payload and destination Direct address to a HISP via SOAP or REST." Does this statement indicate that we are requiring REST or SOAP to be the edge protocol if a HISP deployment model is used, or does this indicate that we are recommending SOAP or REST. Need to mention that there doesn’t need to be a HISP. "The functionality of a HISP can be internal to your system or hosted externally."

Community Feedback and Comments Joe Hall – IG - Technical Guidance – Obviously, in "2. Frequency" there are three options while the text says two. Option 3 seems like an extension of Option 2... you could have "Transmit frequency: [as patient record is updated, monthly, quarterly, etc.]"

Community Feedback and Comments Joe Hall – IG - Privacy & Security Presumably patients will need X.509 certificates issued to them to receive S/MIME encrypted Direct messages... is this handled in the process of receiving a Direct address? Do these messages go to their own (in which case client support for S/MIME is a question) or to a "Direct provider portal" (a service that provides Direct addresses, viewing, etc.)? I sincerely apologize if this is a total Noob question. What is a PCHR? – Personally Controlled Health Record

Community Feedback and Comments Sean Nolan – tion%2BGuide_Direct_ v1+%28SPN+Comments%29.docx tion%2BGuide_Direct_ v1+%28SPN+Comments%29.docx Doug Wager – tion%2BGuide_Direct_ v1%2B%28SPN%2BDWager%2BComments%29. docx tion%2BGuide_Direct_ v1%2B%28SPN%2BDWager%2BComments%29. docx

Community Feedback and Comments Arien Malec – tion+Guide_Direct_ v1-am.docx tion+Guide_Direct_ v1-am.docx

Community Feedback and Comments Dwayne Eriksen – Implementation+Outlines %2B%28DEE %2BComments%29.docx Implementation+Outlines %2B%28DEE %2BComments%29.docx – tion%2BGuide_Direct_ v1%2B%28DEE%2BComments%29.docx tion%2BGuide_Direct_ v1%2B%28DEE%2BComments%29.docx – Make sure that our scope is consistent and that we are not scoping out what a data holder is or what a receiver is. We are focusing on provider to patient, but would not restrict others.

Community Feedback and Comments Greg Meyer – In the "push implementation outlines" document, the guide specifies using a MIME type of application/xml+ccd. There has been discussion in the 360 exchange group of of whether or not using unregistered structured syntax names is appropriate (+ccd in this case). How this group come to consensus that this is using the unregistered syntax is appropriate? How specific do we need to get here? We need to look at other initiatives/projects to see how CCD is being handled

Community Feedback and Comments Joe Hall – User Story 1 – In step 4 in Assumptions, it says, "Provider is responsible for “in person” identity validation." This is a pretty big assumption, but addressing it further may be out of scope for our work. I see two sides of a spectrum here: casual validation like what is done for alcohol sales (and sometimes this requires a magnetic stripe reader but I doubt that's terribly secure) or more intense validation like what the TSA does at airport checkpoints (that requires hours of training). I don't think we expect providers to mimic the TSA with their staff training, but what I'd hate to see is medical identity theft promulgated by fraudulent ABBI registrations based off of fake ID or poor human processes. It sounds like this would be reflected in the Policy Questions column with guidance for this?

Community Feedback and Comments Shelly Spiro – Reviewed the User Story and IG -no comments

Flow 1: Patient Portal 1. Patient logs into portal2. Patient clicks on “Share with Direct” 3. Patient reads and accepts transmit terms 4. Patient enters Direct address and selects transmit frequency

Next Steps / Reminders 21 Next Steps – Focus on Automation/Triggers – Use Cases Meeting Reminders – Next PUSH Workgroup Meeting is Monday, November 12 th, 2:00 pm Eastern. – The next Community Meeting will be held as needed. – For questions, please contact your support leads – Initiative Coordinator: Pierce Graham-Jones (pierce.graham- – Presidential Innovation Fellow: Ryan Panchadsaram – Project Manager: Jennifer Brush – S&I Admin: Apurva Dharia

Webex Chat Content Joe Hall to All Participants: I.C "The functionality of a HISP can be internal to your system or hosted externally." Joe Hall to All Participants: Ah, PHR is now PCHR Bob Pflug to All Participants: Are four scenarios on the table? Bob Pflug to All Participants: provider1->provider2, provider1->PCHR->provider2, provider2- >provider1, provider2->PCHR->provider1 Bob Pflug to All Participants: So Pierce suggests scope is the second scenario (proxy for provider1- >patient or PCHR) Joe Hall to All Participants: Direct hasn't sought a registered MIME type? that seems surprising. Doug Wager to All Panelists: Sorry, I didn't articulate very well, but I think you captured it -- my main point was that ABBI can be agnostic about where he patient wants the data sent -- we're supporting them getting it wherever they need it (PHR, another MD, etc.). Agree it is different from Dwayne's point after you clarified -- ABBI not defining provider ability to receive patient-sent info. Joe Hall to All Participants: Direct doesn't support anonymous transmission, right? (Seems like it could not, but I may be wrong.) Doug Wager to All Panelists: Provider needs to validate that the person asking the data to be sent is the person who owns the data Joe Hall to All Participants: yes Doug Wager to All Panelists: Something I haven't heard discussed -- to meet ABBI, will an organization need to provide both methods? Or if they can support one, will that suffice? Doug Wager to All Panelists: (use cases)