Automate Blue Button Initiative All Hands Community Meeting

1. Automate Blue Button InitiativeAll Hands Community Meeting August 29, 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 Weekly Meetings Please check the meeting schedule weekly as the meeting link and call in numbers will change • 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 4

5. Announcements (cont’d) New! • 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 • Current Discussions: • General ABBI Discussion • PUSH Project Workgroup Discussion • Any requests? We’ll create the discussion page for you!

6. Proposed Workgroups PushProject Pull Project • 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 3rd 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 Content Sub-Group 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 6

7. Workgroup 1: Push PUSH Automating transmission of personal health data to a specific location EXAMPLE USE CASES 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. 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 REQUIREMENTS & ASSUMPTIONS IN SCOPE (TO BE CONSIDERED) OUT OF SCOPE (NOT TO BE CONSIDERED) • 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 • Patient/Provider is already authenticated in dataholder’s system. • Transport must be secure • Data sent must be both human-readable and machine-readable • 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 PULL • Allowing a third party application to access my personal health data on demand 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) • Authentication, transport, and content standards. • Leverage REHx project (Oauth and OpenID) • Leverage ToC project • Leverage lab interface project • 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 • 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 CONTENT A Blue Button file must be both machine-readable and human-readable. EXAMPLE USE CASES A patient can download a copy of his/her records and is able to read and print it out. A patient can point a software or web application to their Blue Button file and it can parse it. REQUIREMENTS & ASSUMPTIONS IN SCOPE (TO BE CONSIDERED) CHALLENGES • Leverage work done by HL7 and Consolidated CDA • Leverage work done by the ToC S&IInitative • File must be both human-readable on multiple platforms: PC, Mac, iOS, and Android • File must be printable • File needs to be machine readable • 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 Comment from wiki. 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:

11. Comment Evaluation Comment from wiki. 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.

12. Comment Evaluation Comment from wiki. 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:

13. Comment Evaluation Comment from wiki. 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:

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

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 • 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. Automate Blue Button Project CharterValue / Vision Statement Moved Vision Statement to beginning. Edited based on feedback. Please review. • 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 16

17. Automate Blue Button Project CharterChallenge and Goals Edited based on feedback. Please review. • 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 Buttonof 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 Buttonon 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 3rd 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 17

18. Automate Blue Button Project CharterScope Statement No change since 8/22. 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 18

19. Automate Blue Button Project CharterSuccess Metrics Needs further community input on outcome measures 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 parsingconsuming/utilizing Blue Button data Number of patients using applications that are powered by Blue Button 19

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

21. Automate Blue Button Project CharterExpected Deliverables No change. 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 21

22. Automate Blue Button Project CharterRelevant Standards & Stakeholders Edited based on feedback. Please review. • 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) • 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. 22

23. Consensus on the Project Charter 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 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)

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

25. Viewing your vote 5 Automate Blue Button Project Charter Consensus Vote Jane Smith Committed Member Note: All Consensus Votes are due Sept 17th by 8:00 pm EST 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

26. Next Steps • Next Steps • Vote on the Project Charter (starting Friday): • 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 • 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

27. Contact Information 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 Management: Jennifer Brush (jennifer.brush@esacinc.com) • S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)

28. Useful Links • Automate Blue Button Wiki • http://wiki.siframework.org/Automate+Blue+Button+Initiative • 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 28