Automate Blue Button Initiative Push Workgroup Meeting

1. Automate Blue Button InitiativePush Workgroup Meeting March 25, 2013

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 has moved to a bi-weekly schedule. • Next Push Workgroup Meeting is scheduled for Monday, April 8, 2013 @ 2:00 pm Eastern. • Meeting information is on the Automate Blue Button Wiki Page: http://wiki.siframework.org/Automate+Blue+Button+Initiative 4

5. C-CDA Scorecard Presentation – April 2, 2013 • “Getting SMART about C-CDA: Faster Meaningful Use with Clinical Benefits” • Description: Presentation on generating high-quality C-CDAs put on by SMART Platforms / Harvard Medical School. You'll recognize 2 items on the agenda that our workgroup contributed to, the C-CDA Scorecard and Sample C-CDAs! • Date: Tuesday, April 2, 2013 @ 12:00 Noon Eastern • Register here: • http://www.eventbrite.com/event/5835539255/mcivte?utm_source=ABBI

6. Dates: June 3 – 4, 2013 • Location: Omni Shoreham Hotel (Washington, DC) • Health Datapalooza IV (HDP IV) is the fourth annual national conference born from government efforts to liberate health data. The conference is a forum that features the newest and most innovative and effective uses of health data by companies, startups, academics, government agencies and individuals. • Sessions of Interest • “Powering Applications Using Consumer Data: Blue Button + For Developers. “ • “Unlocking Clinical & Claims Data by Giving Consumers Access: Blue Button + For Data Holders” • Be a part of it (Deadline April 5) • http://healthdatapalooza.org/present • Panel spots are also open (dataholders & developers) • Registration ends May 24. • $750 Standard • $495 Govt/Academic/Non-profit • More information here: http://healthdatapalooza.org/ • Register here: http://healthdatapalooza.eventbrite.com/

7. May 9, 2013 – Direct Connect a Thon May 9, 2013 20-30 minute presentation slots available Contact Greg Meyer http://wiki.directproject.org/May+2013+Connect-A-Thon

8. Directory Service – Follow Up • Connect BB+ Push Account • https://github.com/jmandel/bluebutton-push-workflow • https://moqups.com/moqupsssss/gs8DXpwK • Comment (Justin) re: discovery mechanism / directory workflow • Central Repository (is unspecified, would have to be hosted, etc.) • Currently almost using existing protocols; with minor changes could use existing protocols (e.g. OAuth2) • There are existing solutions that can be applied to this. • Next Step • Josh & Justin meet to identify and document concerns • Work to understand the gap between the workflow and the existing protocols • April 8 call we will begin with this item 

9. Privacy & Security Section Discussion • http://bluebuttonplus.org/privacy.html • Continuing to work with HHS to clarify questions related to policy. • Additional Questions? • (Pierce) There was some concern about using the Patient bundle. Anyone else experienced this? • Comment (Adrian): Have letter from Office of Civil Rights about how HIPPA is to be interpreted when it comes to patients accessing their record; can we get a similar. • Response: Patient can send it via unsecured email, as long as the consumer understands the risk. (Already in the P&S guidance). • Self-signed certificates ok as long as the patient is known to the practice. Can be an agreement entirely between the physician and the patient (as long as it is not prohibited by technology). • Comment (Josh): Agree. Patient can insist on unsecure email. Patient can also insist on Direct address (secure), but the technology may not support it. • Comment (Adrian): Requesting a specific piece of guidance involving a direct email address for a patient. Vendors are looking to be able to charge for interfaces; when a patient requests that the data be sent elsewhere, it conflicts with the business model.

10. Privacy & Security Section Discussion (cont’d) • Comment (Joe H.): Is there a way to ask the question to OCR that will alleviate this concern? Recommend both software that supports the trust bundle, and something that supports a patient request for the self-signed certificate model, etc. Is there anywhere that constrains the trust bundle? • Comment (Greg): Many options for adding self-signed certificates; real question is how to include/incorporate that self-signed as an achor in the trust store? • Comment (Josh): Policy guidance for unencrypted request is very clear. We want similar guidance on what if a patient requests email to any direct address that a patient specifies. • Question: Can a patient specify any direct address that they want their information to be sent to? And should the provider have to be able to support that use case? The challenge is how do you get them to take the BB+ trust bundle? • Clarification (Pierce): Patient use any direct address, and be able to use that with their provider; provider has to be able to support sending to any direct address. There is an easy way to get it into the bundle, which is the patient bundle. • (Adrian): Technically, addition of the certificate to the trust store could be part of the verification cycle.

11. Extending the IG(Virinder B.) • Additional Details in IG (around triggers and automation) • Patient-defined triggers • Patient goes to provider and requests specific triggers for when to send (e.g. any change in the record triggers an update to N direct addresses). • Consider adding examples to the IG • Screen mock-ups • Other triggers • MU 2 requires documents based on 2 event types, would be a natural starting point • Key Question: What should be included in the C-CDA document? • Options for sending C-CDA to Patient-specified address • Send once (recent encounter / end of encounter) • Send once (whole record) • Send updates at a specific time interval (min / max determined by specific system capabilities (?) • concern: may put stress on the system; flood the patient with information; not all updates may be necessary • Send updates based on specific event • Destinations: patient-specified address, PHR, other provider, • Consider expanding section based on recommended practices on triggers • Next Step • Create menu of options to pick from (whole record, trigger options) • Draft the outline / sections for adding to the IG

12. Next Steps / Action Items(for April 8 meeting) • Triggers and Automation • Virinder to outline sections fro adding to the IG; present to the Push Workgroup April 8 • Directory Workflow • Josh & Justin to meet; identify and document concerns & presentation • Work to understand the gap between the workflow and the existing protocols • April 8 Workgroup call will begin with this as an agenda item

13. Events and Meeting Reminders • Events • C-CDA Webinar: April 2 @ 12:00 – 1:00 Eastern (http://www.eventbrite.com/event/5835539255/mcivte?utm_source=ABBI) • Health Datapalooza: June 2 – 3, 2013 (http://healthdatapalooza.org/) • Meeting Reminders • Next PUSH Workgroup Meeting is Monday, April 8, 2013 @ 2:00 pm Eastern. • 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: Apurva Dharia (apurva.dharia@esacinc.com)

14. Next Steps for ABBI Pull WG • Adoption • Focus on data holder adoption (vendors, providers, & payors) • Focus on developers of 3rd Party applications that would like to design based on the ABBI IG • ACTION: Identify opportunities for us to get vendors / providers / payors on board with BB+ • Dedicated Destination on BlueButtonPlus.Org for Tool Kit items • Consolidated CDA Score Card *!* • NIST Testing Tools • Style Guide Libraries (from Design Challenge) • Button / Icon design options (standards) • Receivers: note any patterns in the data / setup that are negative / incorrect, please let us know so that we can help identify those now • IG Expansion • Facilitate usability and not require a user to have their Direct address • Flesh out the specifics of the Directory Service (based on Josh M’s work).

15. Appendix Previous Meeting Slides

16. Implementation Guidance http://bluebuttonplus.org/

17. HIMSS Summary and Recap • Bill Clinton & Farzad M. had a BlueButton+ mention in their keynote speeches. \o/ • Quest Diagnostics announced that they are going to adopt BlueButton+ [both Point of Care and Gazelle (mobile app)] • THIS IS BECAUSE OF YOUR HARD WORK!!!! • Important for us to get the word out about why this work is important and this kind of mention will help. • Fantastic demonstration results at the interoperability showcase (4 kiosks). A big thank you to all of the implementers / adopters / dataholders / vendors / organizations. • BlueButton+ presentations were conducted on the Interoperability Showcase stage (huge turnout!); leadership (Pierce G-J) also participated in a panel on consumer engagement. • 100+ people / traffic through the demonstrations • ACTION: (ABBI Support Team) Watch HIMSS site for presentation links; cross-link to the wiki / send to the community • ABBI Meet and Greet on Tuesday night • Adrian G. connected with the MITRE consent team about moving BB+ into HIE. • ACTION: (ABBI Community) Let us know if you are doing follow-up blogs / etc. about HIMSS demo results and we’ll cross post / tweet • Demonstrations of C-CDA Generation / from the data side was very good. Some were generating ~80% on the C-CDA ScoreCard.

18. Discussion • Challenge is scaling the solution; need to make it easy for a data holder to tell the user what the direct address is / how to get one. • Proposed solutions (focused on usability): • Education • In-patient movement • MS solution for boot-strapping a patient’s regular email address (implemented in the MS Direct stack); is an alternate option for patient who does not yet have a Direct address when in the clinical setting. • “Do you have direct address? No. That’s okay, just give us your regular email address.” Scenario: A direct message is sent to a special address at HealthVault and contains the patient’s email and kicks off a ‘patient connect’ process – generates an email back to the patient about how to connect HealthVault with a Direct Address, etc. with instructions. • Blog post that describes using the "new user" functionality for HealthVault via Direct: http://blogs.msdn.com/b/familyhealthguy/archive/2011/02/24/more-on-adding-direct-patient-messaging-to-an-ehr.aspx • Provider directory as global resource may not be the most elegant / scalable solution, given the distributed intent/nature of Direct.

19. Discussion (Cont’d) DoD & VA will have an increased reliance on BlueButton record downloads (Announced in Feb 2013) [and subsequently using Direct as a means of transmission b/w] Question: Direct Ref implementations that are available have the code that was used at HIMSS. Yes. [Direct] Question: Should the IG contain example of how to connect w/BB+ Push, for example Thunderbird? For situation where HISP were not involved, e.g. an application developer wanting to become a destination for BB+(Push). Response: Sample of enabling STA functionality for a particular destination. 1) S-MIME: most recipients should be able to intake these (as long as the anchors are there); 2) Source perspective is totally different, mainly around the certificate discovery piece; however, the same concept applies. [ABBI: Directional piece of Direct needs to be addressed in the IG; Data senders are configured to ‘send only’ they won’t see it; issue is existing reference implementations cannot process that NDN and get a false negative]