Automate Blue Button InitiativePayor Content Workgroup

WEDI Pre-Conference

Reston, VirginiaOctober 22, 2012

Synopsis (Draft)

• 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

Focus on patients & consumers accessing their own digital health data

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Proposed Embedded Machine-Readability

Examples

Self-Displaying CDAhttp://wiki.hl7.org/index.php?title=Self_Displaying_CDA

JSON Blue Buttonhttps://github.com/blue-button/smart/blob/master/smart-blue-

button.html

Email: MIMEhttp://tools.ietf.org/html/rfc1521

PDF with embedded datahttp://www.adobepress.com/articles/article.asp?p=1271244

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

Why Machine-Readability leads to better Human-Readability

USA’s best designers + Data Standards + Open Source Code = better design for everyone

Example from Wired Magazine 2010

“The Blood Test Gets a Makeover”

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Example Use Cases under Consideration:Emerging Blue Button App & Service Categories

View & Link• Patient education• Preference-sensitive care• Comparing & reconciling patient-level payor EOBs vs. provider bills

Share & Combine• Care Coordination & PCMH activities & services• Medication reconciliation & adherence tools• Care Team indexing & name / ID sharing with other providers

Interpret• 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Standards being identified by ABBI Workgroups

Container

Content• Capable• Recommended• Required

Transport“Automate”

“Blue Button”

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

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

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.

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.

Implications for Public Health & Education:Immunization Registry Example

PATIENTS & CARE-GIVERS

Clinics, Registries

, Payor Data

Patient & Parents

Blue Button

File

Schools & Camps

DIRECT protocol

(if available)HISP HISP

See directproject.org for more info on the DIRECT protocol

Context: 3rd-Party Developer InputRecommended Financial Data Fields

Recommended FieldsPaid amountDeductible amountCoinsurance amountCopay amountCOB amountEmployee member paidExplanatory codesBilled amountAllowed 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

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Strawman 1: MyMedicare.gov Blue Button

MyMedicare.gov Blue Button Data FileCurrent 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

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Example: Medicare Blue Button

Mymedicare.gov

13

Strawman 2: ASC 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

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

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

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Strawman 4: Microsoft Healthvault EOB Specification

Main Informationhttp://developer.healthvault.com/types/type.aspx?id=356fbba9-e0c9-4f4f-b0d9-4594f2490d2f

XML Schemahttp://developer.healthvault.com/types/schema.aspx?id=356fbba9-e0c9-4f4f-b0d9-4594f2490d2f Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

HealthVault EOB Specification

HealthVault EOB Specification

Strawman 5: Minnesota Uniform EOB

• 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

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

Payer Content WG Status & Timeline

Pre-Discovery

☐ Create synopsis, post for comment & feedback

☐ Create charter, challenge, stakeholder, timelines & milestones

☐ Define goals & outcomes

Discovery

☐ 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

☐ Create Harmonized Specification

☐ Relevant documentation e.g. Implementation Guides, Design Documents

☐ Revise Harmonized Specification & documentation

☐ Transition Plan to Open Source & public-private consortia/communities

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

WG Launch(10/5)

Nov-12

Pre-Discov.

S&I Framework Accelerated Lifecycle

Sep-12 Mar-13

Discovery Implementation Guide

Oct-12 Dec-12 Jan-13 Feb-13

Revise &assess (e.g. feasibility vs. utility)

Define Scope & Aims

Solidify Use Cases

Review standards; harmonize

Generate impl. guides for suppliers

and developers

Initial Draft of Scope & AimsReviewed 2 “straw-men”Reviewed 3 use case areasEngage WEDI community 10/22Agree upon aims & func. Reqs.

Timeline

Outstanding Issues

Standards Identified

Accomplishments Status

Payer Content WG Dashboard

Proposed accelerated timeline

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

You’re invited!ABBI Payor Content Workgroup

24

– 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:

http://wiki.siframework.org/Automate+Blue+Button+Initiative

Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov