Automate blue button initiative payer workgroup meeting
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

Automate Blue Button Initiative Payer Workgroup Meeting PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Automate Blue Button Initiative Payer Workgroup Meeting. October 26, 2012. 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

Download Presentation

Automate Blue Button Initiative Payer Workgroup Meeting

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Automate blue button initiative payer workgroup meeting

Automate Blue Button InitiativePayer Workgroup Meeting

October 26, 2012

Meeting etiquette

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




Announcements and reminders

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

    • Meeting information is on the Automate Blue Button Wiki Page:


Next steps reminders

Next Steps & Reminders

  • Follow-up from Last Two Meetings: Homework

    • Standard that current blue button file is getting pulled from (UHG/OptumHealth example posted)

    • At least one comment on each straw-man standard so far (esp. re: utility & feasibility)

Automate blue button initiative payer workgroup meeting

  • Payer Content WG Current Status



Draft scope presented at wedi 10 22

Draft Scope Presented at WEDI 10/22

Draft Charter for S&I Community Review on the Wiki

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



Schematic presented at wedi 10 22 updated 10 26

Schematic presented at WEDI 10/22Updated 10/26



  • Content

  • Capable

  • Recommended

  • Required


“Blue Button”

For payors = Standardized EOB, or Standard Claims Info

but.. ideally Consolidated CDA + financial data?

Contacts:[email protected]& [email protected]

Feedback comments discussion from wedi fall conference 2012 1 2

Feedback, Comments & Discussionfrom 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)

Feedback comments discussion from wedi fall conference 2012 2 2

Feedback, Comments & Discussionfrom 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)



We need you to vote comment

We Need You to VOTE (+/- comment)


Use Case Prioritization



Payer content standards options for blue button to review as of 10 26

Payer Content Standards Options for Blue Button to Review (as of 10/26)

Emerging options as of 10 26 as organized by c officer thanks chuck

Emerging Options as of 10/26As organized by C. Officer (thanks Chuck!)

More Feasible

More Useful

Consolidated CDA, no financial info

Option 1 + Financial Appendix as EDI 835 (either EDI or XML), separate file from CDA

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.

Go to HL7 and ask to create another section (like CCD) in CDA specifically for EOBs based on 835

Go to HL7 and ask to create another section with EOB + more (e.g. health savings account balances etc.)



Minnesota uniform eob standard

Minnesota Uniform EOB Standard

Source & 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

Contacts:[email protected]& [email protected]

Design challenge 2012 http healthdesignchallenge com

Design Challenge 2012

Visual Design for Consolidated CDA

Can we, the ABBI Payer Workgroup, pave the way to run the same play for payor data, e.g. X12 835-based data?

Proposal embedded machine readability

Proposal:Embedded Machine-Readability


Self-Displaying CDA


JSON Blue Button

e.g. Styles and JSON data embedded in single HTML file

IHE XDM .zip file

PDF with embedded data

e.g. machine-readable and human-readable – separate but part of whole

Email: MIME

Contacts:[email protected]& [email protected]

Reminders contact

Reminders / Contact

  • Meeting Reminders

    • The next Community Meeting will be held on Wednesday, October 31, 2012.

    • The next Payor Workgroup Meeting is Friday, November 2, 2012 @ 1:00 pm Eastern.


  • For questions, please contact your support leads

    • Initiative Coordinator: Pierce Graham-Jones ([email protected])

    • Presidential Innovation Fellows:

      • Henry Wei, MD ([email protected]) for PayorWG

      • Ryan Panchadsaram ([email protected]);

    • Project Manager: Jennifer Brush ([email protected])

    • S&I Admin: ApurvaDharia ([email protected])



Health financial data issues raised so far

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)

Implications for healthcare affordability

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

  • 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,

Implications for personal healthcare quality

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.

Implications for personal health affordability

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.

Strawman 1 mymedicare gov blue button

Strawman 1: Blue Button Blue Button Data File

Current footprint = ~35 million eligible lives


  • 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


  • Include clinical quality data

  • A Codes – unbilled codes used for quality reporting

Example medicare blue button

Example: Medicare Blue Button


Strawman 2 x12 835 health care claim payment advice

Strawman 2: X12 835 : Health Care Claim Payment/Advice

X12 835 Version 5010 : required for nearly every insurance transaction


  • Header Level

    • Amount

    • Payee

    • Payer

    • Trace number

    • Payment method

  • Detail Level

    • EOB information

    • Adjudicated claims and services

  • Summary level

    • Provider adjustment


Potential standards

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


Strawman 3 create a new cda eob template

Strawman 3: Create a new CDA EOB template

Potential XML template for CDA Implementation Guide


  • 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


  • See

Generic components of an eob

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

Draft use cases as of 10 19

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)

Microsoft healthvault eob specification

Microsoft Healthvault EOB Specification

Main Information

XML Schema

Healthvault eob specification

HealthVault EOB Specification

Healthvault eob specification1

HealthVault EOB Specification

3 rd party developer recommended financial data fields

3rd-Party Developer Recommended Financial Data Fields


  • 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

Recommended Fields

Paid amount

Deductible amount

Coinsurance amount

Copay amount

COB amount

Employee member paid

Explanatory codes

Billed amount

Allowed amount

  • Login