Automate Blue Button InitiativePayor Content WorkgroupWEDI Pre-ConferenceReston, VirginiaOctober 22, 2012
Synopsis (Draft)    Focus on patients & consumers accessing their own digital health data•    Aim = Identify a content sta...
Proposed Embedded Machine-Readability               Examples                                                      Illustra...
Why Machine-Readability leads to better Human-Readability                                                                 ...
Example Use Cases under Consideration:    Emerging Blue Button App & Service CategoriesView & Link•    Patient education• ...
Standards being identifiedby ABBI Workgroups          Container            Content          • Capable           Transport ...
Implications for Healthcare AffordabilityComments from an S&I Expert   Comments from Keith Boone   •   [Patients will not ...
Implications for Personal Healthcare Quality:Clinical Decision Support Example    Claims data-driven analytics focused on ...
Implications for Personal Health Affordability:Personal Health Cost Prediction Example    Claims data-driven cost predicti...
Implications for Public Health & Education: Immunization Registry ExampleClinics, Reg         Patient &                   ...
Context: 3rd-Party Developer InputRecommended Financial Data Fields Recommended Fields           Rationale: Paid amount   ...
Strawman 1: MyMedicare.gov Blue Button                               MyMedicare.gov Blue Button Data File                 ...
Example: Medicare Blue Button          Mymedicare.gov                                13
Strawman 2: ASC X12 835 : Health Care ClaimPayment/Advice          X12 835 Version 5010 : required for nearly every insura...
ASC X12 Potential Standards  • Standards for sharing claims information with beneficiaries     – ASC X12 835 (Electronic A...
Strawman 3: Create a new CDA EOB template                   Potential XML template for CDA Implementation Guide          F...
Generic components of an EOB  •   Payer’s Name & Address  •   Provider of services  •   Dates of service  •   Services or ...
Strawman 4:Microsoft Healthvault EOB SpecificationMain Informationhttp://developer.healthvault.com/types/type.aspx?id=356f...
HealthVault EOB Specification
HealthVault EOB Specification
Strawman 5:Minnesota Uniform EOB Source & Standard: http://www.health.state.mn.us/auc/eobremitmanual2007.pdf• Stems from M...
Payer Content WG Status & Timeline                  ☐   Create synopsis, post for comment & feedback  Pre-Discovery   ☐   ...
Payer Content WG Dashboard           Accomplishments                                       Status           Initial Draft ...
You’re invited!ABBI Payor Content Workgroup –   Open to the entire public & private Standards & Interoperability community...
Upcoming SlideShare
Loading in …5
×

WEDI Pre-Conference Blue Button Presentation from Automate Blue Button Initiative payor workgroup

504 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
504
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

WEDI Pre-Conference Blue Button Presentation from Automate Blue Button Initiative payor workgroup

  1. 1. Automate Blue Button InitiativePayor Content WorkgroupWEDI Pre-ConferenceReston, VirginiaOctober 22, 2012
  2. 2. 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
  3. 3. Proposed Embedded Machine-Readability Examples Illustrations Self-Displaying CDA http://wiki.hl7.org/index.php?title=Self_Displaying_CDA JSON Blue Buttonhttps://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
  4. 4. 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  5. 5. 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  6. 6. Standards being identifiedby ABBI Workgroups Container Content • Capable Transport • Recommended • Required “Automate” “Blue Button” Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  7. 7. 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 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-
  8. 8. 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.
  9. 9. 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.
  10. 10. 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 directproject.org for more info on the DIRECT protocol
  11. 11. 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  12. 12. 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
  13. 13. Example: Medicare Blue Button Mymedicare.gov 13
  14. 14. 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: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Strawman 4:Microsoft Healthvault EOB SpecificationMain Informationhttp://developer.healthvault.com/types/type.aspx?id=356fbba9-e0c9-4f4f-b0d9-4594f2490d2fXML Schemahttp://developer.healthvault.com/types/schema.aspx?id=356fbba9-e0c9-4f4f-b0d9-4594f2490d2f Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov
  19. 19. HealthVault EOB Specification
  20. 20. HealthVault EOB Specification
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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 24 Contacts: Pierce.Graham-Jones@hhs.gov & Henry.Wei@va.gov

×