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.
1. Automate Blue Button Initiative
Payor Content Workgroup
WEDI Pre-Conference
Reston, Virginia
October 22, 2012
2. Agenda
• Overview of Blue Button
(20 minutes)
• Working Session on “Automated Blue Button”
for Payors
(50 minutes)
• Open Discussion
(20 minutes)
3. Blue Button
Background
• 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. Blue Button
How 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
6. Draft Charter for S&I
Scope 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. Standards being identified
by ABBI Workgroups
Container
Content
• Capable Transport
• Recommended
• Required “Automate”
“Blue Button”
For payors = Standardized EOB, or
Standard Claims Information
Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
9. Proposed Embedded Machine-Readability
Examples Illustrations
Self-Displaying CDA
http://wiki.hl7.org/index.php?title=Self_Displaying_CDA
JSON Blue Button
https://github.com/blue-button/smart/blob/master/smart-blue-
button.html e.g. Styles and JSON
data embedded in
IHE XDM .zip file single HTML file
http://wiki.ihe.net/index.php?title=Cross-
enterprise_Document_Media_Interchange
PDF with embedded data e.g. machine-readable
http://www.adobepress.com/articles/article.asp?p=1271244
and human-readable
– separate but part of
Email: MIME whole
http://tools.ietf.org/html/rfc1521
Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
10. Why Machine-Readability leads to better
Human-Readability
“The Blood Test Gets a
Makeover”
Example from Wired
Magazine 2010
USA’s best designers + Data Standards + Open Source Code = better design for everyone
Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
11. 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
12. Implications for Healthcare Affordability
Comments 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-
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. 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. Implications for Public Health & Education:
Immunization Registry Example
Clinics, Reg Patient & Blue Schools &
istries, Payo Parents Button File Camps
r Data
PATIENT
S & CARE-
GIVERS
DIRECT protocol
HISP HISP
(if available)
See directproject.org for more info on the DIRECT protocol
16. Context: 3rd-Party Developer Input
Recommended 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
17. Strawman 1: MyMedicare.gov Blue Button
MyMedicare.gov 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
19. Strawman 2: ASC X12 835 : Health Care Claim
Payment/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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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. 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 ot.com/2012/09/what-abbi-
• 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
23. Strawman 4:
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
Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
26. Strawman 5:
Minnesota Uniform EOB
Source & Standard: http://www.health.state.mn.us/auc/eobremitmanual2007.pdf
• 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
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:
http://wiki.siframework.org/Automate+Blue+Button+Initiative
29
Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov