WEDI Pre-Conference Blue Button Presentation


Published on

Presentation by Pierce Graham-Jones (HHS), Henry Wei MD (Presidential Innovation Fellow/VA), and Lorraine Doo (CMS) at the WEDI Pre-Conference 10/22/12 on Blue Button and the Payor Workgroup of the Automate Blue Button Initiative.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

WEDI Pre-Conference Blue Button Presentation

  1. 1. Automate Blue Button InitiativePayor Content WorkgroupWEDI Pre-ConferenceReston, VirginiaOctober 22, 2012
  2. 2. Agenda • Overview of Blue Button (20 minutes) • Working Session on “Automated Blue Button” for Payors (50 minutes) • Open Discussion (20 minutes)
  3. 3. Blue ButtonBackground • Two years ago, the VA added a simple, easy to recognize “Blue Button” to their patient portal. • Since then, the use of Blue Button has grown into a movement – a commitment by many of the VA country’s largest data holders, including the CMS Federal government – to get personal health Department information out of proprietary silos and into the of Defense hands of the consumers who want a holistic Aetna picture of their health and health care. United + Many more • Over 1 million veterans, members of the military, and Medicare beneficiaries have already downloaded their data through Blue Button. #ABBI 3
  4. 4. Blue ButtonHow It Works Today Today, Blue Button means letting consumers download an ASCII file of their personal health information after they log onto the dataholder’s portal. For example: #ABBI 4
  5. 5. Blue ButtonSample Data Files VA: CMS: #ABBI 5
  6. 6. Draft Charter for S&IScope 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 #ABBI 6
  7. 7. Standards being identifiedby ABBI Workgroups Container Content • Capable Transport • Recommended • Required “Automate” “Blue Button” For payors = Standardized EOB, or Standard Claims Information Contacts: &
  8. 8. Synopsis (Draft) Focus on patients & consumers accessing their own digital health data• Aim = Identify a content standard for payor-generated Blue Button data – Practical – Human-readable – Machine-readable – Capable of conveying both clinical and non-clinical data – Data includes Blue Button offered today – Data includes EOB (Explanation of Benefits) data today• Goal = data & interoperability platform – Feasible for payers & PBMs – Attractive to developers – Foundation to innovative apps & to create personally-controlled solutions – Not the solution itself – but should allow solutions to target clinical quality, affordability, access and the experience of care itself Contacts: &
  9. 9. Proposed Embedded Machine-Readability Examples Illustrations Self-Displaying CDA JSON Blue Button button.html e.g. Styles and JSON data embedded in IHE XDM .zip file single HTML file enterprise_Document_Media_Interchange PDF with embedded data e.g. machine-readable and human-readable – separate but part of Email: MIME whole Contacts: &
  10. 10. Why Machine-Readability leads to better Human-Readability “The Blood Test Gets a Makeover” Example from Wired Magazine 2010USA’s best designers + Data Standards + Open Source Code = better design for everyone Contacts: &
  11. 11. Example Use Cases under Consideration: Emerging Blue Button App & Service CategoriesView & Link• Patient education• Preference-sensitive care• Comparing & reconciling patient-level payor EOBs vs. provider billsShare & Combine• Care Coordination & PCMH activities & services• Medication reconciliation & adherence tools• Care Team indexing & name / ID sharing with other providersInterpret• Forecasting and planning a personal healthcare budget• Integrity (errors, fraud & abuse) detection and assistance services• Quality-related applications & services for Accountable Care Organizations• Clinical decision support (evidence-based)• Navigating affordable care options (e.g. brand vs. generic medication)• Chronic disease management, including personal health tracking (e.g. diabetes)• Automatic pre-population of initial visit forms Contacts: &
  12. 12. Implications for Healthcare AffordabilityComments from an S&I Expert Comments from Keith Boone • [Patients will not only] be able to track all of their clinical data, but theyll 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,
  13. 13. Implications for Personal Healthcare Quality:Clinical Decision Support Example 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.
  14. 14. Implications for Personal Health Affordability:Personal Health Cost Prediction Example 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.
  15. 15. Implications for Public Health & Education: Immunization Registry ExampleClinics, Reg Patient & Blue Schools &istries, Payo Parents Button File Camps r Data PATIENT S & CARE- GIVERS DIRECT protocol HISP HISP (if available) See for more info on the DIRECT protocol
  16. 16. Context: 3rd-Party Developer InputRecommended Financial Data Fields Recommended Fields Rationale: Paid amount • Consistent with info Deductible amount already provided to Coinsurance amount members in EOBs Copay amount • Key payment items COB amount enable individuals to see Employee member paid past health care spend & Explanatory codes budget for future Billed amount • Aims to lower healthcare Allowed amount costs, protects interest of payors Contacts: &
  17. 17. Strawman 1: Blue Button Blue Button Data File Current footprint = ~35 million eligible lives FIELDS SUPPORTED COMMENTS • Demographics • Financial data by claim • Include clinical quality data • Name • Charged • A Codes – unbilled codes • DOB • Approved used for quality reporting • Address • Paid • Phone • Patient may be • Email billed • Eligibility • Diagnosis Code(s) • Effective Date(s) • NDC Drug Code(s) • Plan Contract ID(s) • CPT Codes • Plan Period(s) • UB04 Codes • Plan Name(s) • NPI Codes • Claims Summary • Claim ID • Provider ID • Service Dates Contacts: &
  18. 18. Example: Medicare Blue Button 18
  19. 19. Strawman 2: ASC X12 835 : Health Care ClaimPayment/Advice X12 835 Version 5010 : required for nearly every insurance transaction FIELDS SUPPORTED COMMENTS (TRANSACTION SET) • Header Level • Amount • Payee • Payer • Trace number • Payment method • Detail Level • EOB information • Adjudicated claims and services • Summary level • Provider adjustment Contacts: &
  20. 20. ASC X12 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 20
  21. 21. Strawman 3: Create a new CDA EOB template Potential XML template for CDA Implementation Guide FIELDS SUPPORTED COMMENTS (TRANSACTION SET) • See • Insurer Information • Service Performed http://motorcycleguy.blogsp • Payer ID • Date(s) of service • Name • Price billed can-for-for-healthcare- • Policy Info • Negotiated Price cost.html • Patient Info • Amount Paid • Identifier • Patient Responsibility • Name • Notes • Address • Provider Info • NPI • Identifier • Name • Address • Diagnosis Table • Diagnosis Contacts: &
  22. 22. 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 Contacts: &
  23. 23. Strawman 4:Microsoft Healthvault EOB SpecificationMain Information Schema Contacts: &
  24. 24. HealthVault EOB Specification
  25. 25. HealthVault EOB Specification
  26. 26. Strawman 5:Minnesota Uniform EOB 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: &
  27. 27. Payer Content WG Status & Timeline ☐ Create synopsis, post for comment & feedback Pre-Discovery ☐ Create charter, challenge, stakeholder, timelines & milestones ☐ Define goals & outcomes ☐ Use Cases & Stories, functional requirements ☐ Identify interoperability gaps, barriers, obstacles, costs Discovery ☐ Identify alternative approaches, feasibility tests & prototypes ☐ Identify existing standards, models, artifacts for harmonization ☐ Create Harmonized Specification ☐ Relevant documentation e.g. Implementation Guides, Design Documents Implementation ☐ Revise Harmonized Specification & documentation ☐ Transition Plan to Open Source & public-private consortia/communities Contacts: &
  28. 28. Payer Content WG Dashboard Accomplishments Status Initial Draft of Scope & Aims Timeline Reviewed 2 “straw-men” Reviewed 3 use case areas Standards Identified Engage WEDI community 10/22 Outstanding Issues Agree upon aims & func. Reqs. Sep-12 Oct-12 Nov-12 Dec-12 Jan-13 Feb-13 Mar-13 WG Launch Define Scope & (10/5) Aims Proposed accelerated timeline Solidify Use Cases Review Revise &assess Generate impl. standards; (e.g. feasibility guides for suppliers harmonize vs. utility) and developers Pre-Discov. Discovery Implementation Guide S&I Framework Accelerated Lifecycle Contacts: &
  29. 29. You’re invited!ABBI Payor Content Workgroup – Open to the entire public & private Standards & Interoperability community – Payor Workgroup Meetings are Fridays from 1:00 – 2:00 pm Eastern. – “All-Hands” Community Meeting are on Wednesdays – Meeting information is on the Automate Blue Button Wiki Page: 29 Contacts: &