1. Automate Blue Button Initiative Payer Content Workgroup Meeting November 2, 2012

2. Meeting Etiquette Put phone on MUTE – NOT hold This meeting is being recorded Use the WebEx “Chat” feature to queue questions, comments

3. Goals Container Content Capable Recommended Required Content Capable Recommended Required Transport “Automate” “Blue Button”

4. Payer Content WG Current Status Pre-Discovery October ☐ Create synopsis, post for comment & feedback ☐ Create charter, challenge, stakeholder, timelines & milestones ☐ Define goals & outcomes Discovery November ☐ Use Cases & Stories, functional requirements ☐ Identify interoperability gaps, barriers, obstacles, costs ☐ Identify alternative approaches, feasibility tests & prototypes ☐ Identify existing standards, models, artifacts for harmonization Implementation December to January ☐ Create Harmonized Specification ☐ Relevant documentation e.g. Implementation Guides, Design Documents ☐ Revise Harmonized Specification & “SDK” documentation ☐ Transition Plan to Open Source & public-private consortia/communities

5. Agenda TopicTime Allotted Welcome & Reminder on Voting5 minutes Recap of Last Week’s Comments10 minutes New Developer Perspective & Discussion10 minutes Standards for Review & Human Readability Discussion15 minutes Next Steps / Reminders5 minutes 5

6. Comments from 10/26 Payer Content WG Empower patient, get them the data, then let them figure out what to do with it Potentially high complexity for payers – “may get very complex with all the proprietary information & algorithms used to display the EOB” Payor-generated clinical content moving into Consolidated CDA – Many payors doing this today or soon (e.g. Humana, UnitedHealth, BCBS, Aetna) – Includes diagnosis info also, e.g. ICD-9 (or ICD-10) going in. (MU requires SNOMED for EMRs.) – Clearly caveated as payor data, based on billing information; has been discussed with providers, and they are aware – but what about patients without that prior knowledge? CPT4 is proprietary to the American Medical Association (but CMS uses CPT4, HCPCS, ICD9s) Discussion on ASC X12 835 – 835 provides a good conceptual framework – maybe a different final format, will help us – Patient really wants to know what their personal financial impact is… ultimate financial responsibility. Often EOBs will say “you don’t owe the provider anything.” – Adjustments take place later; e.g. contracted amounts, covered amounts etc. – Concern: “Uneasy” to look to 835 as source for meaningful information to the patient. 835 itself may not be appropriate… ultimately involves a proprietary data model at the carrier. – 837: Maybe patients really what to know what was submitted, versus what was paid. What patients see today vs. what is in ASC X12 835 – 835 contains more info than EOB, e.g. code for procedure vs generic description – What patient really want is the current situation, or summarized status

7. Comments from 10/26 Payer Content WG Eligibility Data – May want to consider also what would come back in an eligibility transaction, Coverage info, responsibility, co-pays, deductibles, insurance, in/out network. Could this be initial set of data to look at to begin with? – Hl7 did put in financial/insurance modules in C32. That might be a starting point. – Data source could first be what is required to be returned in the X12 271 eligibility/verification response transaction. – Then could consider additional data, e.g. here are currently claims submitted and status of the claim. Keith Boone: Where do they go? Insurance ID Cards and CCD & CCDAWhere do they go? Insurance ID Cards and CCD & CCDA – http://motorcycleguy.blogspot.com/2012/10/where-do-they-go-insurance-id-cards- and.html http://motorcycleguy.blogspot.com/2012/10/where-do-they-go-insurance-id-cards- and.html – CCD and cCDA template: Coverage Activity, with Policy Activity (list of policies, with policy or program activities) – Issue identified by Lloyd McKenzie: not every insurer has an HL7 OID (though payer IDs will become available soon)

8. Comment related to HIPAA & Privacy Sources: http://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/righttoaccessmemo.pdfhttp://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/righttoaccessmemo.pdf http://www.govhealthit.com/news/ocr-tells-patients-use-legal-right-health-data-access http://www.youtube.com/watch?v=JY1l5s8ED5c Note: Memorandum Leon Rodriguez -- director of the Office of Civil Rights Director noted that some health care orgs mistakenly think HIPAA privacy and security rules restrict their ability to give patients their own medical records "We're hearing more and more about widespread issues, patients being denied or obstructed in their access to their records.” “HIPAA is a valve not a blockage, and it needs to be understood that way.” Patients also have a right to correct health record, to submit a written statement of disagreement “HIPAA says you have to sign consent to send information, provider has to be able to share that with a payer.” – workgroup comment 10/26/12

9. Agenda TopicTime Allotted Welcome & Reminder on Voting5 minutes Recap of Last Week’s Comments10 minutes New Developer Perspective & Discussion10 minutes Standards for Review & Human Readability Discussion15 minutes Next Steps / Reminders5 minutes 9

10. Value Proposition of Blue Button for Insurers Developer Perspective 11/2/12 Value of making EDI-type Codified Financial Data available to consumers 1.Reduced call volume & operational costs -- other entities can participate in reconciling and closing the claim quickly and correctly 2.Patient satisfaction: direct and painless access to all relevant data; clarity on what to pay and why 3.Provider network satisfaction: more patients pay their bills - reduction of bad debt (esp. with high-deductible CDHP) 4.Competitive advantage: allows integration (“mashup”) of other consumer driven products/services to further reduce claim cost (healthier patients) 5.Employer segment will begin to make member self-service access to their own data a factor in selecting health plans “Price transparency is also important because the current system favors bad quality providers. Once it becomes clear that for example [Hospital A] is cheaper and a lot better quality than [Hospital B], it will apply the right pressure on providers to improve quality.”

11. Preferred Payer Content Format Developer Perspective 11/2/12 “Anything is good as long as it’s electronic – better than mail!” “There is no other standard besides ASC X12 835 & 837 [for the type of data we are dealing with]...” “[We] would prefer Quicken banking-type format, too, e.g. XML format, represents everything.” Patient-controlled ASC X12 835 data would be “awesome”, solves for 80% of the needs, but still has some needs – “Deductible, co-pay, and nitty-gritty details” especially those that are important to TPAs – Employer wrap-arounds – Reimbursements paid to the patient vs. the provider “The first question I have [as a patient/member] is: how much do I owe? How do I know this is the correct amount?” Highly preferred if this can be done via pull-model OAuth-style server-to-server transport (although content standard useful) – should reduce operational costs for insurer as well vs. EDI feeds

12. Developer Needs (proposed as Goals) Developer Perspective 11/2/12 Key Needs from the Developer/Solutions Community 1.“Get the technical details done fast and correctly” 2.“Clear, standard, working code and SDKs” 3.Insurers & other data suppliers (PBMs) to signal their intent & commitment to make the data available, e.g. via the Blue Button Pledge Community (healthit.gov/pledge) 4.Automation standards (see Push & Pull workgroups)

13. Agenda TopicTime Allotted Welcome & Reminder on Voting5 minutes Recap of Last Week’s Comments10 minutes New Developer Perspective & Discussion10 minutes Standards for Review & Human Readability Discussion15 minutes Next Steps / Reminders5 minutes 13

14. Payer Content Standards Options for Blue Button to Review (as of 11/2) Option Human ReadableEligibilityProviderRxDiagProcFinancial MyMedicare.gov ASCII YYYYYYY 835 Remittance (X12)NYY Y NCPDP D.0 YYY 837 Submission (X12)NYY Y NCPDP D.0 YYY Proposed cCDA extension (XML) NYY?YYY Consolidated CDA N (Y w/ XSLT) Y*YYYYN HealthVault EOB Type (XML) * With apps N?YNYYY Intuit Health Expense Format (?) ??????? Embedded 835 (proposed) YYY Y NCPDP D.0 YYY Others? (Please propose)

15. Potential Blue Button Download Delivery Patterns for Patient/Member Portals Payer Claims Database Payer Claims Database Patient / Member Portal.PDF ASCII.XLS ?.XLS ?.XML ?.XML ? Self- Displaying Embedded Data? Self- Displaying Embedded Data?

16. Proposal: Embedded Interoperability in a Human-Readable File Examples Self-Displaying CDA http://wiki.hl7.org/index.php?title=Self_Displaying_CDA Self-Displaying CDA http://wiki.hl7.org/index.php?title=Self_Displaying_CDA JSON-in-HTML Blue Button https://github.com/blue-button/smart/blob/master/smart-blue- button.html JSON-in-HTML Blue Button https://github.com/blue-button/smart/blob/master/smart-blue- button.html Email: MIME http://tools.ietf.org/html/rfc1521 Email: MIME http://tools.ietf.org/html/rfc1521 PDF with embedded data http://www.adobepress.com/articles/article.asp?p=1271244 PDF with embedded data http://www.adobepress.com/articles/article.asp?p=1271244 IHE XDM.zip file http://wiki.ihe.net/index.php?title=Cross- enterprise_Document_Media_Interchange IHE XDM.zip file http://wiki.ihe.net/index.php?title=Cross- enterprise_Document_Media_Interchange Illustrations e.g. Styles and JSON data embedded in single HTML file e.g. machine-readable and human-readable – separate but part of whole Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.govPierce.Graham-Jones@hhs.govHenry.Wei@va.gov

17. Self-Contained Human-Readable Interoperability Standards from EMR & HIE world.XML CDA document with CSS instruction.XML CDA document with CSS instruction CSS Style Sheet + Self-Displaying CDA HL7 Standard http://wiki.hl7.org/index.php?title=Self_ Displaying_CDA XDM IHE Standard Cross-Enterprise Document Media Interchange http://wiki.ihe.net/index.php?title=Cros s- enterprise_Document_Media_Interchan ge.zip file container Index.html Index.html Readme.txt Readme.txt IHE_XDM folder SUBSET folder DOC.xml DOC.xml META DATA.xml META DATA.xml.xsl Style Sheet.xsl Style Sheet

18. Design Challenge 2012 http://healthdesignchallenge.com Visual Design for Consolidated CDA … ABBI Payer WG standard will pave the way for designers to run the same play for payor data, e.g. X12 835-based data

19. Agenda TopicTime Allotted Welcome & Reminder on Voting5 minutes Recap of Last Week’s Comments10 minutes New Developer Perspective & Discussion10 minutes Standards for Review & Human Readability Discussion15 minutes Next Steps / Reminders5 minutes 19

20. ABBI Workgroup Meetings, Site & Contacts 20 Fridays 1-2p ET: Payor Content Workgroup Meetings Wednesdays: All-Hands Community Meetings Web Site with meeting details, materials, discussions and recordings: http://wiki.siframework.org/Automate+Blue+Button+Initiative http://wiki.siframework.org/Automate+Blue+Button+Initiative Contacts: Initiative Coordinator: Pierce Graham-Jones (pierce.graham- jones@hhs.gov)pierce.graham- jones@hhs.gov Presidential Innovation Fellows: – Henry Wei MD (henry.wei@va.gov) for Payer Content WGhenry.wei@va.gov – Ryan Panchadsaram (ryan.panchadsaram@hhs.gov)ryan.panchadsaram@hhs.gov Project Manager: Jennifer Brush (jennifer.brush@esacinc.com)jennifer.brush@esacinc.com S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)apurva.dharia@esacinc.com

21. Appendix

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

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

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

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

26. Strawman 1: MyMedicare.gov Blue Button MyMedicare.gov Blue Button Data File Current footprint = ~35 million eligible lives 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 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 COMMENTS Include clinical quality data A Codes – unbilled codes used for quality reporting

27. Example: Medicare Blue Button Mymedicare.gov 27

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

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

30. 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 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.blogsp ot.com/2012/09/what-abbi- can-for-for-healthcare- cost.html http://motorcycleguy.blogsp ot.com/2012/09/what-abbi- can-for-for-healthcare- cost.html COMMENTS See http://motorcycleguy.blogsp ot.com/2012/09/what-abbi- can-for-for-healthcare- cost.html http://motorcycleguy.blogsp ot.com/2012/09/what-abbi- can-for-for-healthcare- cost.html

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

32. Draft Use Cases as of 10/19 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)

33. Microsoft Healthvault EOB Specification Main Information http://developer.healthvault.com/types/type.a spx?id=356fbba9-e0c9-4f4f-b0d9-4594f2490d2f XML Schema http://developer.healthvault.com/types/schem a.aspx?id=356fbba9-e0c9-4f4f-b0d9- 4594f2490d2f

34. HealthVault EOB Specification

36. 3 rd -Party Developer Recommended Financial Data Fields Recommended Fields Paid amount Deductible amount Coinsurance amount Copay amount COB amount Employee member paid Explanatory codes Billed amount Allowed amount Rationale: Consistent with info already provided to members in EOBs Key payment items enable individuals to see past health care spend & budget for future Aims to lower healthcare costs, protects interest of payors

37. Appendix: WEDI 10/22 Meeting Recap & Feeedback 37

38. Draft Scope Presented at WEDI 10/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 Presented at WEDI 2012 Fall Conference, Health IT Business & Policy Impact http://www.wedi.org/forms/meeting/MeetingFormPublic/view?id=1C37D00000210 38 Draft Charter for S&I Community Review on the Wiki #ABBI

39. Schematic presented at WEDI 10/22 Updated 10/26 Container Content Capable Recommended Required Content Capable Recommended Required Transport “Automate” “Blue Button” Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.govPierce.Graham-Jones@hhs.govHenry.Wei@va.gov For payors = Standardized EOB, or Standard Claims Info but.. ideally Consolidated CDA + financial data?

40. Feedback, Comments & Discussion from WEDI Fall Conference 2012 (1/2) Plan-to-Plan PHR Standard is worth looking at, was ASC, developed by BCBS and AHIP. HL7 component was based on CCD. Did not contain financial data though. (commenter) ASC X12 835 satisfies what this needs (commenter) Family History may be an interesting use case (commenter) Timestamping is important. Time, place – design it NOW. Lesson learned from data warehouses, can’t go back and timestamp things. Long-term members are interested in narratives that fit into the narratives of their lives. If you want to portray a narrative, these info points will need underlying structure. (Max ___, commenter) What about making this available/accessible to patients? Need clear messaging – lousy today. E-mail also not a good thing. (commenter) Have you considered Dental Data (Kathryn Jonzzon) Need some way to correct the data (commenter) Maybe could include a VOID list, to actually convey not only the data, but what we knew to be corrected (Henry Wei)

41. Feedback, Comments & Discussion from WEDI Fall Conference 2012 (2/2) Claims data not perfect – but errors were in the data already. Blue Button doesn’t cause those errors – but DOES allows patients & consumers to finally at last see all their data. Still need to allow some 2-way communication & process to handle that error correction (Martin Jensen) When people download their ASCII files today, they start emailing their own PHR around. Potential abuse seems pretty hi; EMR seems more secure (Matt Warner) How many people really use this? Provider & payor % utilization is extremely low, PHR, EHRs, and payor portals do this already. Are we premature? We don’t have standards. We should let the industry work its way out. (commenter; ed. – may need clarification that this is a standard & brand for those PHRs, EHRs & portals) Personal story: my Medicare file had almost all the medical history incorrect, and also received an e-mail from Medicare in the clear with prevent service reminders. Very worried about security, privacy, and encryption. (commenter) Concern that EOB-type data has lower credibility, e.g. EOB has wrong date – couldn’t tell what was included – different name of other doctor who had billed for MD – not sure what it meant, e.g. negotiated rate (commenter) Feel “victimized” by Healthplan with “rule-out” diagnosis codes, as the health plan kept reaching out and contacting for a condition that I didn’t have; drugs were reclassified as COPD disease, and anurse wanted to help manage. Be careful with the data! (commenter)

42. Appendix: Options Review

43. Emerging Options as of 10/26 As organized by C. Officer (thanks Chuck!) 1.Consolidated CDA, no financial info 2.Option 1 + Financial Appendix as EDI 835 (either EDI or XML), separate file from CDA 3.Option 1 + Financial Appendix, but map EDI 835 to HL7 C62 standard (like a “Misc.” section of CDA). One file, but could take a long time to map, and more like free form text. 4.Go to HL7 and ask to create another section (like CCD) in CDA specifically for EOBs based on 835 5.Go to HL7 and ask to create another section with EOB + more (e.g. health savings account balances etc.) More Feasible More Useful

44. Minnesota Uniform EOB Standard Stems from Minnesota HealthCare Administrative Simplification Act (ASA) of 1994 Payers can raise consumer awareness and strengthen customer satisfaction Set of administrative standards and simplified procedures throughout the industry Consistent industry guidelines Source & Standard: http://www.health.state.mn.us/auc/eobremitmanual2007.pdf