Automate Blue Button Initiative Payor Workgroup Meeting

1. Automate Blue Button InitiativePayor Workgroup Meeting October 12, 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 • Payor Workgroup Meetings are Fridays from 1:00 – 2:00 pm Eastern. • The next Community Meeting will be held on Wednesday, October 17, 2012. • Meeting information is on the Automate Blue Button Wiki Page: http://wiki.siframework.org/Automate+Blue+Button+Initiative 4

5. Sub-Group: Payor Content A payor- or PBM-generated Blue Button file must be both human-readable and machine-readable (interoperable). Use Cases A patient can download a copy of his/her Medical & Rx Claims records, read & print them out A patient can point an application or service to their Blue Button file and parse it for value-added function, e.g. education; clinical decision support; personal finance • REQUIREMENTS • AND ASSUMPTIONS • File content standard must allow for common data elements in Blue Button ASCII files today • Eligibility Dates • Diagnosis Codes • Procedure Codes • Rx Codes • Financial Information • IN SCOPE • (TO BE CONSIDERED) • Leverage existing elements defined by public & private payors • Leverage existing standards if possible e.g. X12, HL7, cCDA extension • Produce implementation guidance • CHALLENGES • AND TACTICS • Need for practical, lower-effort & low-maintenance standards that can be implemented, e.g. using existing standards • Should be of value to downstream developers, e.g. personal health finance applications, education, decision support providers • Should have sufficient data to be of some clinical utility

6. Health Financial Data: Issues Raised So Far Health Financial Data • Is Financial data in-scope? • Unlike “traditional” clinical health data • Patient advocate organization represented in broader ABBI community meetings have expressed it as a priority, however • Could be a “home run” for the ABBI Community if it enables more affordable care. But if not us, who else will tackle this? • Solutions are out-of-scope; data standards & interoperability in-scope, and pre-requisite for 3rd-parties to create solutions. • How are patients getting it today? • Explanations of Benefit (EOBs)  concern about proprietary network discounting information, may need QH Policy-like stipulations! • Limited electronic access today (mostly PDF and/or “scraping” aggregators like Simplee & Cake Health)

7. Implications for Healthcare Affordability Comments from Keith Boone • [Patients will not only] be able to track all of their clinical data, but they'll also be able to track costs of particular illnesses. • The apps this content will support will be able link EOB data back to clinical data, so that patients can understand the true cost of a given diagnosis. • Patients could also agree to share the content anonymously to third parties (in exchange for other services using that data).   • Thus, a patient could give access to anonymized data that links services, diagnoses and costs, to particular aggregators.   • The aggregators could agree (similar to the QH Policy Sandbox) to certain stipulations on use of the data, with the patient.  See http://wiki.siframework.org/Query+Health+Policy+Sandbox • The aggregator would then be able to analyze and generate cost information for illness, by provider, payer, policy and region.  Such data could be used to enable patients to obtain: • For a given diagnosis and plan, average costs for services and providers in their region. • For given diagnoses, the expected annual out-of-pocket costs for providers that the patient uses, based on historical data. • The upside for payers is that access to such data across payers will enable them to drive costs downward. Source: “What ABBI can do for Healthcare Cost Transparency”, 9/13/12, http://motorcycleguy.blogspot.com/2012/09/what-abbi-can-for-for-healthcare-cost.html

8. Implications for Personal Healthcare Quality Claims data-driven analytics focused on Clinical Decision Support & Quality are currently available to large self-insured employers, but not directly to consumers Through analysis of “rough” ICD-9, CPT, and NDC-coded data, these existing organizations can run “n-of-1” quality measures for individual patients & consumers.

9. Implications for Personal Health Affordability Claims data-driven cost prediction is currently available to insurers & large employers, but not yet directly to consumers Individuals may be able to help predict & budget for their health care spending needs, if they have a level-playing-field & access to the same data used by actuaries & underwriters.

10. Use Cases in Blue Button “App Ecosystem” Emerging Blue Button App & Service Categories • Patient education • Care Coordination & PCMH activities & services • Quality-related applications & services for Accountable Care Organizations • Clinical decision-making, for both evidence-based decisions as well as preference-sensitive care • Finding and understanding more affordable care options (e.g. brand vs. generic medication) • Forecasting and planning a personal healthcare budget • Chronic disease management, including personal health tracking (e.g. diabetes) • Medication reconciliation & adherence tools • Integrity (errors, fraud & abuse) detection and assistance services • Patient-provider communication and scheduling (e.g. automatic pre-population of initial visit forms, triage of health issues, and scheduling & transportation support)

11. Strawman 1: MyMedicare.gov Blue Button MyMedicare.gov Blue Button Data File Current footprint = ~35 million eligible lives • FIELDS SUPPORTED • Demographics • Name • DOB • Address • Phone • Email • Eligibility • Effective Date(s) • Plan Contract ID(s) • Plan Period(s) • Plan Name(s) • Claims Summary • Claim ID • Provider ID • Service Dates • Financial data by claim • Charged • Approved • Paid • Patient may be billed • Diagnosis Code(s) • NDC Drug Code(s) • CPT Codes • UB04 Codes • NPI Codes • COMMENTS • Include clinical quality data • A Codes – unbilled codes used for quality reporting

12. Example: Medicare Blue Button Mymedicare.gov 12

13. Strawman 2: X12 835 : Health Care Claim Payment/Advice X12 835 Version 5010 : required for nearly every insurance transaction • FIELDS SUPPORTED (TRANSACTION SET) • Header Level • Amount • Payee • Payer • Trace number • Payment method • Detail Level • EOB information • Adjudicated claims and services • Summary level • Provider adjustment • COMMENTS

14. Potential Standards • Standards for sharing claims information with beneficiaries • ASC X12 835 (Electronic Admittance Advice) - Health plan that contains multiple patient information to one provider • NCPDP D.0 telecommunication for pharmacy claims and remittance • ASC X12 837 (Health Care Claim Transaction Set) - File of 837 claims from a healthcare provider will contain multiple claims destined to either one payer or clearinghouse for multiple payers • Claim Submission • Post Adjudicated Claims • No EOB standard identified other than above • Typically a proprietary format exchanged • Minnesota print standard format • Other standards being considered for payer exchange of clinical information • Claims attachment to CCD • Payer data mapping to CCD • PHR to PHR standard being developed by HL7 / WEDI 14

15. Strawman 3: Create a new CDA EOB template Potential XML template for CDA Implementation Guide • FIELDS SUPPORTED (TRANSACTION SET) • Insurer Information • Payer ID • Name • Policy Info • Patient Info • Identifier • Name • Address • Provider Info • NPI • Identifier • Name • Address • Diagnosis Table • Diagnosis • Service Performed • Date(s) of service • Price billed • Negotiated Price • Amount Paid • Patient Responsibility • Notes • COMMENTS • See http://motorcycleguy.blogspot.com/2012/09/what-abbi-can-for-for-healthcare-cost.html

16. Generic components of an EOB • Payer’s Name & Address • Provider of services • Dates of service • Services or procedure code numbers • Diagnosis codes and/or Rx codes • Amounts billed by the provider • Reductions or denial codes • Claim control number • Subscriber’s and patient’s name and policy numbers • Analysis of the patient’s total payment responsibility • Amount not covered • Co-payment • Deductibles • Coinsurance • Other insurance payment • Patient’s total responsibility • Total amount paid by the payer

17. Next Steps & Reminders • Homework • Please come back to next meeting (10/19) with the standard that your current blue button file is getting pulled from. Be ready to present your sample blue button file. Consider sharing it on wiki / send to organizers to post in advance. • Everyone: please send or post at least one comment on each straw-man standard so far. Please focus on utility & feasibility of implementing as a standard for payor-generated Blue Button. • WEDI 2012 Fall Conference • Health IT Business & Policy Impact • Monday, October 22

18. Reminders / Contact • Meeting Reminders • The next Community Meeting will be held on Wednesday, October 17, 2012. • The next Payor Workgroup Meeting is Friday, October 19, 2012 @ 1: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 Fellows: Ryan Panchadsaram (ryan.panchadsaram@hhs.gov); Henry Wei, MD (henry.wei@va.gov) for Payor WG • Project Manager: Jennifer Brush (jennifer.brush@esacinc.com) • S&I Admin: ApurvaDharia (apurva.dharia@esacinc.com)