Download - WEDI Pre-Conference Blue Button Presentation from Automate Blue Button Initiative payor workgroup
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
Standards being identified by ABBI Workgroups
Container
Content• Capable• Recommended• Required
Transport“Automate”
“Blue Button”
Contacts: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]
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: [email protected] & [email protected]