1. Automate Blue Button Initiative All Hands Community Meeting August 29, 2012

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

3. Agenda TopicTime Allotted Welcome and Announcements5 minutes Workgroup Formation50 minutes Project Charter Review – Comment Review20 minutes Consensus Process Overview (time permitting)10 minutes Next Steps / Reminders5 minutes 3

4. Announcements The Automate Blue Button Initiative will hold weekly community meetings on Wednesdays at 3:00 pm Eastern. – To participate, please see the “Attend the Weekly Community Meeting” section of the Automate Blue Button Wiki Page: http://wiki.siframework.org/Automate+Blue+Button+Initiative Please check the meeting schedule weekly as the meeting link and call in numbers will change Weekly Meetings 4

5. Announcements (cont’d) NEW: Discussion Board on the ABBI Wiki – Discussions will be indexed / linked from the main Discussion Board page – http://wiki.siframework.org/ABBI+Discussion+Board http://wiki.siframework.org/ABBI+Discussion+Board – Current Discussions: General ABBI Discussion PUSH Project Workgroup Discussion Any requests? We’ll create the discussion page for you! New!

6. Push Project Pull Project Content Sub-Group Proposed Workgroups Automating transmission of personal health data to a specific location Discovery: review existing standards and formulate project charter and scope Work on use cases Define deliverables and timeline Scope input needed on content and privacy and security Allowing a third party application to periodically access my personal health data on demand Discovery: review existing standards and formulate project charter and scope Work on use cases Define deliverables and timeline Scope input needed on content and privacy and security Note: Pull may include patient action only, not necessarily only 3 rd party A Blue Button file must be machine-readable and human-readable Review existing efforts and standards to leverage Develop plan to support PUSH and PULL projects Consider as: CCDA 6

7. Workgroup 1: Push Automating transmission of personal health data to a specific location By patient request, a provider can specify in an EHR that a patient be sent an updated copy of his/her personal health information as it becomes available A patient can specify in a dataholder’s system to be sent an updated copy of his/her personal health information as it becomes available. PUSH EXAMPLE USE CASES REQUIREMENTS & ASSUMPTIONS IN SCOPE (TO BE CONSIDERED) OUT OF SCOPE (NOT TO BE CONSIDERED) Patient/Provider is already authenticated in dataholder’s system. Transport must be secure Data sent must be both human-readable and machine-readable Patient/Provider is already authenticated in dataholder’s system. Transport must be secure Data sent must be both human-readable and machine-readable Transport standards, services, and specifications Content standards: whether or not to include in implementation guide(s) Implementation guide(s) to support use case(s), building off existing standards Transport standards, services, and specifications Content standards: whether or not to include in implementation guide(s) Implementation guide(s) to support use case(s), building off existing standards Policy concerns and constraints. This initiative will define the mechanism, – how and where they apply it will be up to state and local laws 7

8. Workgroup 2: Pull Allowing a third party application to access my personal health data on demand PULL EXAMPLE USE CASE A patient can direct a third party application to have on demand access to his/her personal health information via the internet. The dataholder will ensure this data is made available and follow certain privacy and security standards. REQUIREMENTS & ASSUMPTIONS IN SCOPE (TO BE CONSIDERED) OUT OF SCOPE (NOT TO BE CONSIDERED) Data must be transmitted securely Patient must give application consent to pull health information from data holder Data sent must be both human-readable and machine-readable Data must be transmitted securely Patient must give application consent to pull health information from data holder Data sent must be both human-readable and machine-readable Authentication, transport, and content standards. Leverage REHx project (Oauth and OpenID) Leverage ToC project Leverage lab interface project Authentication, transport, and content standards. Leverage REHx project (Oauth and OpenID) Leverage ToC project Leverage lab interface project Policy concerns and constraints. This initiative will define the mechanism, – how and where they apply it will be up to state and local laws 8

9. Sub-Group: Content A Blue Button file must be both machine-readable and human-readable. A patient can point a software or web application to their Blue Button file and it can parse it. A patient can download a copy of his/her records and is able to read and print it out. CONTENT EXAMPLE USE CASES REQUIREMENTS & ASSUMPTIONS IN SCOPE (TO BE CONSIDERED) CHALLENGES File must be both human- readable on multiple platforms: PC, Mac, iOS, and Android File must be printable File needs to be machine readable File must be both human- readable on multiple platforms: PC, Mac, iOS, and Android File must be printable File needs to be machine readable Leverage work done by HL7 and Consolidated CDA Leverage work done by the ToC S&I Initative Leverage work done by HL7 and Consolidated CDA Leverage work done by the ToC S&I Initative A cross-platform file that is self contained. Enabling easy-parsing of the file. Should take a developer less than 3 minutes to use. A cross-platform file that is self contained. Enabling easy-parsing of the file. Should take a developer less than 3 minutes to use. 9

10. Comment Evaluation Topic: PULL Project Scope Comment Focus: Generalizing application behaviors Comment Text: “While I agree that some vendors might be concerned about PULL, I don't think this is generalize-able as an EHR vendors trend, and I certainly don't believe this to be as strong an issue in the HIE or patient portal space, where patients are already being granted secure online access. I don't agree that we can generalize about desirable application behaviors from a small sample of responses. I would argue that PUSH and PULL should get equal attention, and should have a great deal of compatibility between them (e.g., as Direct and Exchange do).” [Keith W. Boone, GE Healthcare] Draft Disposition: Accepted with Modifications: Push and Pull will be getting equal attention. Discussion Summary: 10 Comment from wiki.

11. Comment Evaluation Topic: PULL Project Scope Comment Focus: Response to Keith Boone Comment Text: “I would agree that both should require equal attention. Working for a healthcare system, I'm hoping to provide context for discussion and thought. Case 1: We are a large healthcare system in a major metropolitan area that has a primary clinical information system for the hospital. Within our healthcare system, we also have physician EMR's from multiple vendors. As a healthcare system, we have the option of unifying our presence to the consumer (i.e. a single website). On that website, we could potentially have our consumers, with the click of a button, download a single file containing clinical records from the hospital system and the physician EMR's (i.e. the pull model). This assumes that the vendors who have supplied information systems to the hospital and the EMR are able to support a protocol to authenticate the user and transport those documents from multiple sources at the same time. My question (perhaps this is up to vendor or even an in-house developer), what guidelines are there to standardize the aggregation of data from the source? Case 2: We could have the same scenario as above but our hospital clinical information system and the physician EMR's are part of an HIE. Here the HIE could support a protocol to authenticate the user and transport a single document. Under this scenario, the HIE can house the data in aggregate and return a single document or HIE is querying multiple data sources to return a single document. In the model above, I feel as if a "consumer access service" (as defined from the Markle Foundation), could serve as the intermediary between a data source and a consumer requesting a download from a website where the standards that will be proposed here could work. Pull is certainly important if the "consumer access service" interacts with a PHR where hopefully more can be done with data. The more relevant question is where can the data be pushed? PHR, e-mail...I think under this context, the framework should consider a short discussion on how "communication preferences" can be honored.”[Sanju Patel, Memorial Hermann Healthcare System] Draft Disposition: Accepted with Modifications: Push and Pull will be getting equal attention. 11 Comment from wiki.

12. Comment Evaluation Topic: PULL Project Scope Comment Focus: Policy Concerns being out of scope Comment Text: “We would like to register concerns that treating policy concerns and constraints as out of scope may allow technological considerations to drive business activities and policy decisions. If technical solutions are identified before policy and business issues are resolved, then those technological solutions may provide an unfair advantage to some stakeholders and put other stakeholders at a disadvantage. Moreover, we disagree with the tacit premise that policy and business decisions about “how and where [the technological solutions or mechanisms] apply” will be solely a function of state and local laws. First, it is unlikely that the federal government will have no role in driving policy decisions. Second, any policy decisions should take into account the business needs and concerns of all affected stakeholders. Therefore, we strongly urge that policy concerns and constraints be brought in scope and integrated into the use cases – allowing stakeholders’ policy and business interests to drive technological considerations..”[Lenel James, Blue Cross & Blue Shield Assoc.] Draft Disposition: Accepted. Agree that policy concerns should not be out of scope. Discussion Summary: 12 Comment from wiki.

13. Comment Evaluation Topic: PUSH Project Scope Comment Focus: Policy Concerns being out of scope Comment Text: “We would like to register concerns that treating policy concerns and constraints as out of scope may allow technological considerations to drive business activities and policy decisions. If technical solutions are identified before policy and business issues are resolved, then those technological solutions may provide an unfair advantage to some stakeholders and put other stakeholders at a disadvantage. Moreover, we disagree with the tacit premise that policy and business decisions about “how and where [the technological solutions or mechanisms] apply” will be solely a function of state and local laws. First, it is unlikely that the federal government will have no role in driving policy decisions. Second, any policy decisions should take into account the business needs and concerns of all affected stakeholders. Therefore, we strongly urge that policy concerns and constraints be brought in scope and integrated into the use cases – allowing stakeholders’ policy and business interests to drive technological considerations.”[Lenel James, Blue Cross & Blue Shield Assoc.] Draft Disposition: Accepted. Agree that policy concerns should not be out of scope. Discussion Summary: 13 Comment from wiki.

14. Workgroup Sign Up Next Step: Sign up for a Workgroup – http://wiki.siframework.org/ABBI+Workgroup+Signup http://wiki.siframework.org/ABBI+Workgroup+Signup Workgroup Sign Up

15. Project Charter Review - Continued Changes have been made to the Project Charter based on your input. We have reviewed and deposed all comments. Details about the disposition for each can be found in the detailed version of the presentation materials for today, on the ABBI Wiki Home page: – http://wiki.siframework.org/Automate+Blue+Button+Initiative http://wiki.siframework.org/Automate+Blue+Button+Initiative Consensus voting will begin Friday, August 31. Consensus voting will end Monday, September 10. Instructions for how to cast your vote are at the end of this presentation. 15

16. 16 Automate Blue Button Project Charter Value / Vision Statement Consumers want to be empowered to be more engaged in their health and healthcare. Through the Blue Button, consumers want the ability to exercise more access to and portability of their health care information. With the right privacy and security assurances, they want to be able to: – Better understand their health and make more informed decisions – Help to make sure that they and all of their care team members are on the same page – Improve the accuracy and completeness of the information – Plug it into apps and tools that promise to make information truly available when and where it’s needed Moved Vision Statement to beginning. Edited based on feedback. Please review.

17. 17 Challenge – How can we advance the implementation standards, tools, and services associated with the Blue Button to provide consumers with automated updates to their health information in a human readable and machine readable format? Goals – PUSH: Automating the private and secure transmission of personal health data to a specific location using the Blue Button of the consumer’s choosing. Consider: Push notification only (e.g. alert) to patient that new data is available. – PULL: Allowing a third party application of the consumer’s choosing to privately and securely access personal health data using the Blue Button on demand. Note: Best Practice Guidelines of Markle - machines should use a different entry point/mechanism in order to manage user identity Need machine readable version of BB content first Concern: too easy for a 3 rd party to get my information that I don’t want them to have; take it without my permission Concern: ability of a patient to specify / identify data that can / cannot be shared Auditing: ability to log what was transported when and where; auditable view for customer support purposes Automate Blue Button Project Charter Challenge and Goals Edited based on feedback. Please review.

18. 18 Automate Blue Button Project Charter Scope Statement Identify, define, and harmonize implementation standards, tools and services that facilitate the automated PUSH and automated PULL of patient information via the Blue Button Identify, define and harmonize content structures and specifications for the Blue Button so that information downloaded is machine readable and human readable Identify, define, and harmonize protocols around identification and credentialing, and protocols around access and authorization, that facilitate the automated PUSH and automated PULL of patient information via the Blue Button No change since 8/22.

19. 19 Automate Blue Button Project Charter Success Metrics For dataholders: Number of existing BB dataholders that implement Auto Blue Button Number of new dataholders that take the pledge and implement Auto Blue Button Consider outcome measures as project progresses For patients: Number of patients that access their data using Blue Button Number of patients that use new features of Blue Button (both push and pull) Consider outcome measures as project progresses For third-parties: Number of application developers parsing consuming/utilizing Blue Button data Number of patients using applications that are powered by Blue Button Needs further community input on outcome measures

20. 20 Automate Blue Button Project Charter Target Milestones & Timelines Driving Milestones Pilot Push implementation by November 22, 2012 Pilot Pull implementation by March 3, 2013 Reconsider when Workgroup Charters are complete

21. 21 Automate Blue Button Project Charter Expected Deliverables Workgroup Charters Use Case(s) and Functional Requirements Standards for Blue Button Implementation Guidance for Blue Button Tool development to support Blue Button Pilots and results No change.

22. 22 Automate Blue Button Project Charter Relevant Standards & Stakeholders DIRECT: A set of transport standards, services, and use cases that any data holder or receiver can implement, to package and send/receive electronic health information in a private and secure fashion. ToC Content Recommendations: Recommendations on document structures to fulfill Meaningful Use Stage 2 Transitions of Care requirements (consolidated CDA). (http://wiki.siframework.org/ToC+Document+Recommendations)http://wiki.siframework.org/ToC+Document+Recommendations OAuth & OpenID: Community-developed, industry-standardized protocols for authentication and authorization. (Note: The FHA is currently developing a RESTful approach to information exchange that leverages OAuth and OpenID.) LRI Content Recommendations: Recommendations on document structures for Lab Interfaces to electronic health records RHEx: Working on security standards (OpenID and OAuth) and content standards (working now) for applying a RESTful design approach to exchanging health information. OSEHRA is an open, collaborative community of users, developers, and companies engaged in advancing electronic health record software and health information technology Work to create and encourage adoption of a new CCD to Blue Button “Transform tool” (to support OPM request) Work underway to specify use cases for using EHRs and DIRECT to transmit updated summaries of care to a patient as they become available. Markle Foundation's recommendations for Blue Button (including privacy and security specifications) National Strategy for Trusted Identities in Cyberspace: public-private initiative to create stronger, more consistent cyber identification policies and services. Edited based on feedback. Please review.

23. For those of you who are committed members, we ask you to vote on the Automate Blue Button Project Charter: Yes – A Yes vote does not necessarily mean that the deliverable is the ideal one from the perspective of the Initiative Member, but that it is better to move forward than to block the deliverable Yes with comments – If a Consensus Process attracts significant comments (through Yes with comment votes), it is expected that the comments be addressed in a future revision of the deliverable. Formal Objection- with comments indicating a path to address the objection in a way that meets the known concerns of other members of the Community of Interest. "Formal Objection" vote without such comments will be considered Abstain votes. – A Formal Objection means that the objector cannot proceed with the project unless the objections are met. It is acceptable and expected to use a Formal Objection in a first consensus round to communicate a point of view or process issue that has not been addressed in the drafting of the initial deliverable. – Should a Consensus Process attract even one "Formal Objection" vote with comments from an Initiative Member, the deliverable must be revised to address the "Formal Objection" vote (unless an exceptional process is declared). Abstain (decline to vote) Note: Each Organization, no matter the number of Committed Members only receives 1 Vote. If there are multiple committed members from your organization please verify your collective vote with them Consensus on the Project Charter

24. Submitting your Vote 1.Review the Project Charter: – http://wiki.siframework.org/Automa te+Blue+Button+Project+Charter http://wiki.siframework.org/Automa te+Blue+Button+Project+Charter 2.Complete the Voting Form: – NOTE: You must be a Committed Member to Vote Yes Yes with comments. Formal Objection Abstain (decline to vote) 3.Submit your Vote 4.A Message is displayed verifying your vote was recorded 24 3 3 4 4 1 1 2 2

25. Automate Blue Button Project Charter Consensus Vote Jane Smith Committed Member Viewing your vote 5. View and track your Vote. (Voting record is directly below the Voting Form. Note: you may need to refresh your browser to see your vote 25 5 5 Note: All Consensus Votes are due Sept 17 th by 8:00 pm EST

26. Next Steps 26 Next Steps – Vote on the Project Charter (starting Friday): – http://wiki.siframework.org/Automate+Blue+Button+Project+Charter http://wiki.siframework.org/Automate+Blue+Button+Project+Charter Next Work Group Meeting – 3:00pm - 4:30pm Eastern, Wednesday, September 5, 2012 – http://wiki.siframework.org/Automate+Blue+Button+Initiative http://wiki.siframework.org/Automate+Blue+Button+Initiative All ABBI (ABBI) Announcements, Meeting Schedules, Agendas, Minutes, Reference Materials, Use Case, Project Charter and general information will be posted on the HeD Wiki page – http://wiki.siframework.org/Automate+Blue+Button+Initiative http://wiki.siframework.org/Automate+Blue+Button+Initiative

27. For questions, please contact your support leads Initiative Coordinator: Pierce Graham-Jones (pierce.graham-jones@hhs.gov)pierce.graham-jones@hhs.gov Presidential Innovation Fellow: Ryan Panchadsaram (ryan.panchadsaram@hhs.gov)ryan.panchadsaram@hhs.gov Project Management: Jennifer Brush (jennifer.brush@esacinc.com)jennifer.brush@esacinc.com S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)apurva.dharia@esacinc.com 27 Contact Information

28. Useful Links Automate Blue Button Wiki – http://wiki.siframework.org/Automate+Blue+Button+Initiative http://wiki.siframework.org/Automate+Blue+Button+Initiative Join the Initiative – http://wiki.siframework.org/Automate+Blue+Button+Join+the+Initiative http://wiki.siframework.org/Automate+Blue+Button+Join+the+Initiative Automate Blue Button Project Charter – http://wiki.siframework.org/Automate+Blue+Button+Project+Charter http://wiki.siframework.org/Automate+Blue+Button+Project+Charter 28