Automate Blue Button Initiative Push Workgroup Meeting

1. Automate Blue Button InitiativePush Workgroup Meeting November 5, 2012

2. Meeting Etiquette From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  All Panelists • 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 • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • 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. • Send comments to All Panelists so they can be addressed publically in the chat, or discussed in the meeting (as appropriate). 2

3. Agenda

4. Announcements and Reminders • 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: http://wiki.siframework.org/Automate+Blue+Button+Initiative • Community Homework • Provide comments and feedback on the Push Implementation Guidance Documents: http://wiki.siframework.org/Push+Implementation+Guidance+Comments+and+Feedback 4

5. PUSH Current Status Pre-Discovery • Agreed and voted on charter, including • Scope • Timeline • Deliverables Discovery • Identified priority implementation options: • Transmit requirement of MU Stage 2 (from V/D/T requirement) + automation • Email + file encryption also discussed as option for PUSH • Wrote draft use case for two V/D/T + automation • Write draft use case for Email (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 Email Reference Implementations • 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 • Refine use cases based on reference implementations • Refine implementation guide based on reference implementations Implementations • 3-6 full implementations that reflect implementation guidance 5

6. PushWorkgroup • PUSH Current Deliverables • Use Case Issue List • Implementation guide http://wiki.siframework.org/file/view/ABBI+Push+Implementation+Outlines+10121017.docx http://wiki.siframework.org/file/view/Implementation+Guide_Direct_10-22-12v1.docx 6

7. PushWorkgroup • PUSH Dashboard Next Steps Status • Write policy FAQ document to support PUSH options • Write draft implementation guide for V/D/T + automation • Write draft implementation guide for Email • 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 Timeline Pilots Identified & On Track Outstanding Issues Oct-12 Nov-12 Jan-13 Feb-13 Sep-12 Dec-12 Mar-13 WG Launch (09/17) Reference Implementations using Direct Draft Implementation Guidance Use Case 1 Definition (DIRECT @ Physician’s Office) Finalize Implementation Guidance for Direct Full implementations with providers / Payers Use Case 2 Definition (DIRECT via Patient Portal) Reference Implementations using Email Use Case 3 Definition (Email) UC3 Implementation Guidance for Email Discovery Pilot & Implementation Guidance Implementation 7 S&I Framework Lifecycle

8. Push Implementation Outlines http://wiki.siframework.org/Push+Implementation+Outline+Comments+and+Feedback

9. Implementation Guide – For Example… 9

10. Community Feedback and Comments • Thomson Kuhn • IG - Technical Guidance • B. Handling a Patient’s Request for Transmit 45 C.F.R. § 164.508 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.

11. 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."

12. 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.]"

13. 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 email (in which case email 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

14. Community Feedback and Comments • Sean Nolan • http://wiki.siframework.org/file/view/Implementation%2BGuide_Direct_10-22-12v1+%28SPN+Comments%29.docx • Doug Wager • http://wiki.siframework.org/file/view/Implementation%2BGuide_Direct_10-22-12v1%2B%28SPN%2BDWager%2BComments%29.docx

15. Community Feedback and Comments • ArienMalec • http://wiki.siframework.org/file/view/Implementation+Guide_Direct_10-22-12v1-am.docx

16. Community Feedback and Comments • Dwayne Eriksen • http://wiki.siframework.org/file/view/ABBI+Push+Implementation+Outlines+10121017%2B%28DEE%2BComments%29.docx • http://wiki.siframework.org/file/view/Implementation%2BGuide_Direct_10-22-12v1%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.

17. 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

18. 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?

19. Community Feedback and Comments • Shelly Spiro • Reviewed the User Story and IG -no comments

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

21. Next Steps / Reminders • Next Steps • Focus on Automation/Triggers • Email Use Cases • Meeting Reminders • Next PUSH Workgroup Meeting is Monday, November 12th, 2012 @ 2:00 pm Eastern. • The next Community Meeting will be held as needed. • http://wiki.siframework.org/Automate+Blue+Button+Initiative • For questions, please contact your support leads • Initiative Coordinator: Pierce Graham-Jones (pierce.graham-jones@hhs.gov) • Presidential Innovation Fellow: Ryan Panchadsaram (ryan.panchadsaram@hhs.gov) • Project Manager: Jennifer Brush (jennifer.brush@esacinc.com) • S&I Admin: ApurvaDharia (apurva.dharia@esacinc.com)

22. 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)