Automate Blue Button InitiativePayer Content Workgroup MeetingCharter synopsis: the aim of the ABBI Payer Content workgroup is to identify a practical human-readable and machine-readable content standard for Blue Button data, capable of conveying both clinical and non-clinical health data offered by existing payers today, either by Blue Button or in EOB (Explanation of Benefits) documents today. The goal is to arrive at a data & interoperability platform, feasible for payers & PBMs and attractive to developers to innovative apps & to create personally-controlled solutions that target clinical quality, affordability, access and the experience of care itself.

November 16, 2012

Meeting Reminders

First… THANK YOU workgroup participants for sharing your valuable time & expertise. We are grateful.

• Phone on MUTE – not hold• Meeting being recorded• Use WebEx “Chat” to queue questions & comments

Payer Content WG Current Status

Pre-DiscoveryOctober

☐ Create synopsis, post for comment & feedback

☐ Create charter, challenge, stakeholder, timelines & milestones

☐ Define goals & outcomes

DiscoveryNovember

☐ Use Cases & Stories, functional requirements

☐ Identify interoperability gaps, barriers, obstacles, costs

☐ Identify alternative approaches, feasibility tests & prototypes

☐ Identify existing standards, models, artifacts for harmonization

ImplementationDecemberto January

☐ Create Harmonized Specification

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

☐ Revise Harmonized Specification & “SDK” documentation

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

Agenda

Topic Time Allotted

Data Fields of Interest Discussion: cCDA context 20 minutes

Digital Signatures & Message Authentication 10 minutes

Next Steps / Reminders 5 minutes

4

Near-term optionbalances

cCDA compatibilitywith new data fields

and glide path tocommon

payer-providerstandard

Emerging Options

1. Consolidated CDA, no financial info2. Option 1 + Financial Appendix as EDI

835 (either EDI or XML), separate file from CDA

3. Option 1 + Financial Appendix, but map EDI 835 to HL7 C62 standard (like a “Misc.” section of CDA). One file, but could take a long time to map, and more like free form text.

4. Go to HL7 and ask to create another section (like CCD) in CDA specifically for EOBs based on 835

5. Go to HL7 and ask to create another section with EOB + more (e.g. health savings account balances etc.)

Special thanks to Chuck Officer for organizing this list

More Feasible

More Useful

ABBI Payor WG: Data Fields of Interest 11/9 draft

Financial & Admin Fields Clinical Fields Care Team Fields

Patient Responsibility ($) Medications (NDC codes) Patient Demographics

Paid Amount ($) Procedures (CPT4 codes) Provider IDs & names

Deductible Amount ($) Diagnoses (ICD9/10 codes) Insurer/PBM ID & names

Coinsurance Amount ($) Conditions (SNOMED?)

Coordination of Benefits amount ($) Problem List (SNOMED?)

Explanatory Codes Lab Results (LOINC)

Billed amount ($) Revenue codes (UB04)

Allowed amount ($)

Eligibility Effective Date

Claim ID

Provider ID

Clinical Section Templates 11/16 DiscussionRelevant cCDA Sections for potential adaptation?

cCDA Section Template LOINC Notes

Allergies 48765-2 Req. in CCD; possible from ICD-9 codes?

Hospital Admission Diagnosis

46241-6 Opt. in Discharge Summary

Hospital Discharge Diagnosis

11535-2 Opt in Discharge Summary

Immunizations 11379-7 Opt. in CCD

Interventions 62387-6 Opt. in Progress Note

Medications 10160-0 Req. in CCD & many other templates.

Plan of Care 18776-5 Appropriate for care management / disease management data?

Procedures 47519-4 Opt. in many templates

Results 30954-2 Req. in CCD; Opt. in other templates

Consolidated CDA Payer Section

Payers Section 48768-6

• …contains data on the patient’s payers, whether a ‘third party’ insurance, self-pay, other payer or guarantor, or some combination of payers, and is used to define which entity is the responsible fiduciary for the financial aspects of a patient’s care.

• Each unique instance of a payer and all the pertinent data needed to contact, bill to, and collect from that payer should be included. Authorization information that can be used to define pertinent referral, authorization tracking number, procedure, therapy, intervention, device, or similar authorizations for the patient or provider, or both should be included. At a minimum, the patient’s pertinent current payment sources should be listed.

• The sources of payment are represented as a Coverage Activity, which identifies all of the insurance policies or government or other programs that cover some or all of the patient's healthcare expenses. The policies or programs are sequenced by preference. The Coverage Activity has a sequence number that represents the preference order. Each policy or program identifies the covered party with respect to the payer, so that the identifiers can be recorded.

Consolidated CDAPayers Section Example

Figure 121: Payers section example<section> <templateId root="2.16.840.1.113883.10.20.22.2.18"/> <!-- ******** Payers section template ******** --> <code code="48768-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Payments"/> <title>Insurance Providers</title> <text> <table border="1" width="100%"> <thead> <tr> <th>Payer name</th> <th>Policy type / Coverage type</th> <th>Policy ID</th> <th>Covered party ID</th>

<th>Policy Holder</th> </tr> </thead> <tbody> <tr> <td>Good Health Insurance</td> <td>Extended healthcare / Family</td> <td>Contract Number</td> <td>1138345</td> <td>Patient's Mother</td> </tr> </tbody> </table> </text>

Consolidated CDACoverage Activity Example

<act classCode="ACT" moodCode="DEF"> <templateId root="2.16.840.1.113883.10.20.22.4.60"/> <!-- **** Coverage activity template **** --> <id root="1fe2cdd0-7aad-11db-9fe1-0800200c9a66"/> <code code="48768-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Payment sources"/> <statusCode code="completed"/> <entryRelationship typeCode="COMP"> <act classCode="ACT"

moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.61"/> <!-- **** Policy Activity template **** --> ... </act> </entryRelationship></act>

Consolidated CDAPolicy Activity Example

<act classCode="ACT" moodCode="EVN"> <templateId root="2.16.840.1.113883.10.20.22.4.61"/> <!-- ******** Policy Activity template ******** --> <id root="3e676a50-7aac-11db-9fe1-0800200c9a66"/> <code code="SELF" codeSystemName="HL7RoleClass" codeSystem="2.16.840.1.113883.5.110"> </code> <statusCode code="completed"/> <!-- Insurance Company Information --> <performer typeCode="PRF"> <time/> <assignedEntity> <id root="2.16.840.1.113883.19"/> <code code="PAYOR" codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7RoleCode"/> <addr use="WP"> <!-- HP is "primary home" from codeSystem 2.16.840.1.113883.5.1119 --> <streetAddressLine>123 Insurance Road</streetAddressLine>

<city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> <!--US is "United States" from ISO 3166-1 Country Codes: 1.0.3166.1--> </addr> <telecom value="tel:(781)555-1515" use="WP"/> <representedOrganization> <name>Good Health Insurance</name> <telecom/> <addr/> </representedOrganization> </assignedEntity> </performer> <!-- Guarantor Information The person responsible for the final bill. --> <performer typeCode="PRF"> <time/> <assignedEntity> <id root="329fcdf0-7ab3-11db-9fe1-0800200c9a66"/> <code code="GUAR" codeSystem="2.16.840.1.113883.5.110"

codeSystemName="HL7RoleClass"/> <addr use="HP"> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <telecom value="tel:(781)555-1212" use="HP"/> <assignedPerson> <name> <prefix>Mr.</prefix> <given>Adam</given> <given>Frankie</given> <family>Everyman</family> </name> </assignedPerson> </assignedEntity> </performer> CONTINUED ON NEXT SLIDE…

Consolidated CDAPolicy Activity Example

CONTINUED FROM PREVIOUS SLIDE…<participant typeCode="COV"> <time> <low nullFlavor="UNK"/> <high nullFlavor="UNK"/> </time> <participantRole classCode="PAT"> <id root="14d4a520-7aae-11db-9fe1-0800200c9a66" extension="1138345"/> <!-- Health plan ID for patient. --> <code code="SELF" codeSystem="2.16.840.1.113883.5.111" displayName="Self"/> <addr use="HP"> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> <playingEntity> <name> <!-- Name is needed if different than health

plan name. --> <prefix>Mr.</prefix> <given>Frank</given> <given>A.</given> <family>Everyman</family> </name> </playingEntity> </participantRole> </participant> <participant typeCode="HLD"> <participantRole> <id extension="1138345" root="2.16.840.1.113883.19"/> <addr use="HP"> <streetAddressLine>17 Daws Rd.</streetAddressLine> <city>Blue Bell</city> <state>MA</state> <postalCode>02368</postalCode> <country>US</country> </addr> </participantRole> </participant> <entryRelationship typeCode="REFR"> <act classCode="ACT" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.19"/> <!-- **** Authorization activity template **** --> ... </act> </entryRelationship> ... </entryRelationship></act>

cCDA Health Insurance Type Value Set (excerpt)

Consolidated CDA Reference (12/11 Draft)

http://www.hl7.org/search/viewSearchResult.cfm?search_id=212869&search_result_url=%2Fdocumentcenter%2Fpublic%2Fwg%2Fstructure%2F20111202%5FConsolidation%5FPublication%5FDraft%2Ezip

(Now say that three times fast.)

Financial Templates 11/16 Discussioncontinued from 11/9 discussion

Fields to considerPatient Responsibility ($) Limitations (certain # of visits per

year; how many remaining)Health Plan ID (enumeration begins 2014, required 2016)

Paid Amount ($) Outstanding balances carried forward

Health Plan Name (as in CAQH CORE eligibility inquiry responses)

Deductible Amount ($) In Network/Out of Network Preventive Services

Coinsurance Amount ($) Outstanding balances carried forward

ELIGIBILITY for Wellness & Care Management Services

COB amount ($) (may be challenge to determine what to show)

Claim ID

Explanatory Codes Provider ID as NPI (e.g. as MyMedicare uses)

Billed amount ($)

Allowed amount ($)

Eligibility Effective Date

Care Management Data Field:Use Interoperability to Drive Patient Engagement?

• Often HMOs, insurers & self-insured employers, as well as ACOs, offer health coaching & other wellness benefits free of charge to the beneficiaries. There may even be financial incentives for some of these programs.

• Flagging & signalling the existence of these programs to downstream users – patients, doctors, 3rd-party apps – may be critical to driving engagement.

• Data fields could resemble payer-type data, simplified– Title of Benefit (plain text)– Eligibility Time Period Begin (date)– Eligibility Time Period End (date)– Description (plain text)– Contact/linkage information (e.g. phone number; URL)

Agenda

Topic Time Allotted

Data Fields of Interest Discussion: cCDA context 20 minutes

Digital Signatures & Message Authentication 10 minutes

Next Steps / Reminders 5 minutes

17

Document Integrity & Digital Signatures

• It may be important to have a digital “wax seal” for downstream consumers of the data

• We have heard from healthcare organizations that the lack of document authentication inhibits them from ingesting & incorporating data

• Hashing mechanisms can provide for two key functions• Document Integrity (to ensure it hasn’t been tampered

with)• Document Authorship (to verify who created the document)

Document Integrity & Digital SignaturesHashes

MD5 = Message Digest 5. 128-bit hash, used for integrity check.

SHA1 = NIST developed, FIPS PUB 180-1. Modeled after MD5. 160-bit hash. Greater security.

SHA2 = Family of two similar hash functions, with different block sizes: SHA-256 and SHA-512. Also truncated versions of each standardized, known as SHA-224 and SHA-384. Designed by NSA

Document Integrity & Digital SignaturesHashes

Proposed Data Fields (optional)• Hash method• Message Authentication Code / Message Digest

Can permit flexibility for those seeking only document integrity (e.g. MD5) up to those with secure certificates with digital signatures (e.g. public/private key)

ABBI Workgroup Meetings, Site & Contacts

21

Fridays 1-2p ET: Payor Content Workgroup MeetingsNext meeting after Thanksgiving (no meeting 11/23)

Wednesdays: All-Hands Community MeetingsWeb Site with meeting details, materials, discussions and recordings: http://wiki.siframework.org/Automate+Blue+Button+Initiative

Contacts: • Initiative Coordinator: Pierce Graham-Jones (

pierce.graham-jones@hhs.gov)• Presidential Innovation Fellows:

– Henry Wei MD (henry.wei@va.gov) for Payer Content WG– Ryan Panchadsaram (ryan.panchadsaram@hhs.gov)

• Project Manager: Jennifer Brush (jennifer.brush@esacinc.com)• S&I Admin: Apurva Dharia (apurva.dharia@esacinc.com)

Appendix

Synopsis & Charter from 11/9

Synopsis• The aim of the ABBI Payer Content workgroup is to identify a practical human-

readable and machine-readable content standard for Blue Button data, capable of conveying both clinical and non-clinical health data offered by existing payers today, either by Blue Button or in EOB (Explanation of Benefits) documents today. The goal is to arrive at a data & interoperability platform, feasible for payers & PBMs and attractive to developers to innovative apps & to create personally-controlled solutions that target clinical quality, affordability, access and the experience of care itself.

In Scope• Leverage existing elements defined by public & private payers• Leverage existing standards if possible e.g. MyMedicare.gov ASCII, X12, HL7,

cCDA extension, HealthVault EOB data model• Produce implementation guidance• Payor-generated Health Financial data and Clinical Claims Data• Examples of relevant data : Explanations of Benefit (EOBs) -- with noted

concern about proprietary network discounting information

10Yes

0No

Abstain = 1

Voting Comments & Proposed Mods. (11/9)

Eligibility Data• Insurance approval or service provided or both?Financial Data• [We have some concerns about] expansion of the

scope to replace EOB's/include financial data. Member Usability• Also, I don't believe we should consider the X12

format. We need to focus on formats that will be usable by members and I don't feel X12 will be useful in member settings.

Clarification: What’s the “Ask”?

Proposed standard may be non-binding; probably will not actually require some fields be populated (especially if they are

unavailable, e.g. Rx data for some payers).

For organizations who do want to supply those fields, though, they will benefit from a common content format – especially to be

interoperable with consumer-controlled applications.

Example: For Sensitive Network Discount Information, some organizations may choose to share structured & interoperable

data about PR (patient responsibility) amount only. Others may share the full set of data already available on the paper-based or

PDF-based EOBs (explanations of benefit) sent to the beneficiaries.

ASC X12 is being discussed in a non-traditional sense, as an existing standard that contains the typical fields found in payor-

generated data.

The Use Case is fundamentally different than what X12 is used for today, i.e. consumer-centric data, vs. payer-provider transactions.

Clarification: Dual Aim is relatedGeneralized Use Cases

Human-ReadableMachine-Interoperable

Payer & PBMSupplied

Individual Health Data

Original Claims & Other Data

e.g. X12

Payer and PBBased

Claims & Rx Databases

Front-endMember &

PatientPortals

Consumer-Centric Use Cases (Generalized)

View ShareApps & Services

Aggregate & Reconcile

Human Readability needed

Machine Interop. needed

Interoperability allows Payers & PBMS to Benefit from Shared External Innovation

No Interoperability for Consumer-Facing Uses

Interoperability forConsumer-Facing Uses

A B C D

AppDev 1

AppDev 2

AppDev 3

Consumer apps face an “n-hard” problem today – number of technical negotiations is exponential (handshakes = n * m, where n = # of suppliers and m = # of developers), in addition to probable HIPAA business associate agreements.

SLOW, COMPLICATED, THWARTS INNOVATION.

• Patient is in control of their data• Fewer handshakes needed for data• Risk of innovation shifts from data suppliers

to developers, in exchange for larger accessible market for any given developerFASTER, SIMPLER, DRIVES INNOVATION

A B C D

AppDev 1

AppDev 2

AppDev 3

PCHR*

PCH

R =

Pers

onal

ly-C

ontr

olle

d H

ealth

Rec

ord,

e.g

. Mic

roso

ft H

ealth

Vaul

t

Health Financial Data: Issues Raised So Far

Health Financial Data• Is Financial data in-scope? – Unlike “traditional” clinical health data– Patient advocate organization represented in broader ABBI

community meetings have expressed it as a priority, however– Could be a “home run” for the ABBI Community if it enables

more affordable care. But if not us, who else will tackle this?– Solutions are out-of-scope; data standards & interoperability

in-scope, and pre-requisite for 3rd-parties to create solutions.• How are patients getting it today?

– Explanations of Benefit (EOBs) concern about proprietary network discounting information, may need QH Policy-like stipulations!

– Limited electronic access today (mostly PDF and/or “scraping” aggregators like Simplee & Cake Health)

Implications for Healthcare Affordability

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

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

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.

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

Example: Medicare Blue Button

Mymedicare.gov

33

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

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 35

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

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

Draft Use Cases as of 10/19

Emerging Blue Button App & Service Categories• Patient education• Care Coordination & PCMH activities & services• Quality-related applications & services for Accountable Care Organizations• Clinical decision-making, for both evidence-based decisions as well as

preference-sensitive care• Finding and understanding more affordable care options (e.g. brand vs. generic

medication)• Forecasting and planning a personal healthcare budget• Chronic disease management, including personal health tracking (e.g. diabetes)• Medication reconciliation & adherence tools• Integrity (errors, fraud & abuse) detection and assistance services• Patient-provider communication and scheduling (e.g. automatic pre-population

of initial visit forms, triage of health issues, and scheduling & transportation support)

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

HealthVault EOB Specification

HealthVault EOB Specification

3rd-Party Developer Recommended 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

Appendix: WEDI 10/22 Meeting Recap & Feeedback

43

Draft Scope Presented at WEDI 10/22

• 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

Presented at WEDI 2012 Fall Conference, Health IT Business & Policy Impact http://www.wedi.org/forms/meeting/MeetingFormPublic/view?id=1C37D00000210 44

Draft Charter for S&I Community Review on

the Wiki

#ABBI

Schematic presented at WEDI 10/22Updated 10/26

Container

Content• Capable• Recommended• Required

Transport“Automate”

“Blue Button”

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

For payors = Standardized EOB, or Standard Claims Info

but.. ideally Consolidated CDA + financial data?

Feedback, Comments & Discussionfrom WEDI Fall Conference 2012 (1/2)

• Plan-to-Plan PHR Standard is worth looking at, was ASC, developed by BCBS and AHIP. HL7 component was based on CCD. Did not contain financial data though. (commenter)

• ASC X12 835 satisfies what this needs (commenter)• Family History may be an interesting use case (commenter)• Timestamping is important. Time, place – design it NOW. Lesson learned from data

warehouses, can’t go back and timestamp things. Long-term members are interested in narratives that fit into the narratives of their lives. If you want to portray a narrative, these info points will need underlying structure. (Max ___, commenter)

• What about making this available/accessible to patients? Need clear messaging – lousy today. E-mail also not a good thing. (commenter)

• Have you considered Dental Data (Kathryn Jonzzon)• Need some way to correct the data (commenter)• Maybe could include a VOID list, to actually convey not only the data, but what we

knew to be corrected (Henry Wei)

Feedback, Comments & Discussionfrom WEDI Fall Conference 2012 (2/2)

• Claims data not perfect – but errors were in the data already. Blue Button doesn’t cause those errors – but DOES allows patients & consumers to finally at last see all their data. Still need to allow some 2-way communication & process to handle that error correction (Martin Jensen)

• When people download their ASCII files today, they start emailing their own PHR around. Potential abuse seems pretty hi; EMR seems more secure (Matt Warner)

• How many people really use this? Provider & payor % utilization is extremely low, PHR, EHRs, and payor portals do this already. Are we premature? We don’t have standards. We should let the industry work its way out. (commenter; ed. – may need clarification that this is a standard & brand for those PHRs, EHRs & portals)

• Personal story: my Medicare file had almost all the medical history incorrect, and also received an e-mail from Medicare in the clear with prevent service reminders. Very worried about security, privacy, and encryption. (commenter)

• Concern that EOB-type data has lower credibility, e.g. EOB has wrong date – couldn’t tell what was included – different name of other doctor who had billed for MD – not sure what it meant, e.g. negotiated rate (commenter)

• Feel “victimized” by Healthplan with “rule-out” diagnosis codes, as the health plan kept reaching out and contacting for a condition that I didn’t have; drugs were reclassified as COPD disease, and anurse wanted to help manage. Be careful with the data! (commenter)

Appendix: Options Review

Emerging Options as of 10/26As organized by C. Officer (thanks Chuck!)

1. Consolidated CDA, no financial info2. Option 1 + Financial Appendix as EDI 835

(either EDI or XML), separate file from CDA3. Option 1 + Financial Appendix, but map EDI 835

to HL7 C62 standard (like a “Misc.” section of CDA). One file, but could take a long time to map, and more like free form text.

4. Go to HL7 and ask to create another section (like CCD) in CDA specifically for EOBs based on 835

5. Go to HL7 and ask to create another section with EOB + more (e.g. health savings account balances etc.)

More Feasible

More Useful

Minnesota Uniform EOB 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

Source & Standard: http://www.health.state.mn.us/auc/eobremitmanual2007.pdf

Comments from 10/26 Payer Content WG

• Empower patient, get them the data, then let them figure out what to do with it• Potentially high complexity for payers

– “may get very complex with all the proprietary information & algorithms used to display the EOB”• Payor-generated clinical content moving into Consolidated CDA

– Many payors doing this today or soon (e.g. Humana, UnitedHealth, BCBS, Aetna)– Includes diagnosis info also, e.g. ICD-9 (or ICD-10) going in. (MU requires SNOMED for EMRs.)– Clearly caveated as payor data, based on billing information; has been discussed with providers, and they

are aware – but what about patients without that prior knowledge?• CPT4 is proprietary to the American Medical Association (but CMS uses CPT4, HCPCS, ICD9s)• Discussion on ASC X12 835

– 835 provides a good conceptual framework – maybe a different final format, will help us– Patient really wants to know what their personal financial impact is… ultimate financial responsibility.

Often EOBs will say “you don’t owe the provider anything.”– Adjustments take place later; e.g. contracted amounts, covered amounts etc. – Concern: “Uneasy” to look to 835 as source for meaningful information to the patient. 835 itself may not

be appropriate… ultimately involves a proprietary data model at the carrier.– 837: Maybe patients really what to know what was submitted, versus what was paid.

• What patients see today vs. what is in ASC X12 835– 835 contains more info than EOB, e.g. code for procedure vs generic description– What patient really want is the current situation, or summarized status

Comments from 10/26 Payer Content WG

• Eligibility Data – May want to consider also what would come back in an eligibility transaction,

• Coverage info, responsibility, co-pays, deductibles, insurance, in/out network. • Could this be initial set of data to look at to begin with?

– Hl7 did put in financial/insurance modules in C32. That might be a starting point. – Data source could first be what is required to be returned in the X12 271

eligibility/verification response transaction. – Then could consider additional data, e.g. here are currently claims submitted and

status of the claim. • Keith Boone: Where do they go? Insurance ID Cards and CCD & CCDA

– http://motorcycleguy.blogspot.com/2012/10/where-do-they-go-insurance-id-cards-and.html

– CCD and cCDA template: Coverage Activity, with Policy Activity (list of policies, with policy or program activities)

– Issue identified by Lloyd McKenzie: not every insurer has an HL7 OID (though payer IDs will become available soon)

Comment related to HIPAA & Privacy

Sources: http://www.hhs.gov/ocr/privacy/hipaa/understanding/consumers/righttoaccessmemo.pdfhttp://www.govhealthit.com/news/ocr-tells-patients-use-legal-right-health-data-accesshttp://www.youtube.com/watch?v=JY1l5s8ED5c

• Note: Memorandum Leon Rodriguez -- director of the Office of Civil Rights

• Director noted that some health care orgs mistakenly think HIPAA privacy and security rules restrict their ability to give patients their own medical records

• "We're hearing more and more about widespread issues, patients being denied or obstructed in their access to their records.”

• “HIPAA is a valve not a blockage, and it needs to be understood that way.”

• Patients also have a right to correct health record, to submit a written statement of disagreement

“HIPAA says you have to sign consent to send information, provider has to be able to share that with a payer.” – workgroup comment 10/26/12

Value Proposition of Blue Button for InsurersDeveloper Perspective 11/2/12

Value of making EDI-type Codified Financial Data available to consumers1. Reduced call volume & operational costs -- other entities can participate in

reconciling and closing the claim quickly and correctly2. Patient satisfaction: direct and painless access to all relevant data; clarity on

what to pay and why3. Provider network satisfaction: more patients pay their bills - reduction of bad

debt (esp. with high-deductible CDHP)4. Competitive advantage: allows integration (“mashup”) of other consumer driven

products/services to further reduce claim cost (healthier patients)5. Employer segment will begin to make member self-service access to their own

data a factor in selecting health plans“Price transparency is also important because the current system favors bad quality providers. Once it becomes clear that for example [Hospital A] is cheaper and a lot better quality than [Hospital B], it will apply the right pressure on providers to improve quality.”

Preferred Payer Content FormatDeveloper Perspective 11/2/12

• “Anything is good as long as it’s electronic – better than mail!”• “There is no other standard besides ASC X12 835 & 837 [for the type of data we

are dealing with]...”• “[We] would prefer Quicken banking-type format, too, e.g. XML format, represents

everything.”• Patient-controlled ASC X12 835 data would be “awesome”, solves for 80% of the

needs, but still has some needs– “Deductible, co-pay, and nitty-gritty details” especially those that are

important to TPAs– Employer wrap-arounds– Reimbursements paid to the patient vs. the provider

• “The first question I have [as a patient/member] is: how much do I owe? How do I know this is the correct amount?”

• Highly preferred if this can be done via pull-model OAuth-style server-to-server transport (although content standard useful) – should reduce operational costs for insurer as well vs. EDI feeds

Developer Needs (proposed as Goals)Developer Perspective 11/2/12

Key Needs from the Developer/Solutions Community1. “Get the technical details done fast and correctly”2. “Clear, standard, working code and SDKs”3. Insurers & other data suppliers (PBMs) to signal their intent &

commitment to make the data available, e.g. via the Blue Button Pledge Community (healthit.gov/pledge)

4. Automation standards (see Push & Pull workgroups)

Payer Content Standards Options for Blue Button to Review (as of 11/2)

OptionHuman

Readable Eligibility Provider Rx Diag Proc Financial

MyMedicare.gov ASCII Y Y Y Y Y Y Y

835 Remittance (X12) N Y Y Y NCPDP D.0 Y Y Y

837 Submission (X12) N Y Y YNCPDP D.0 Y Y Y

Proposed cCDA extension (XML) N Y Y ? Y Y Y

Consolidated CDA N (Y w/ XSLT) Y* Y Y Y Y N

HealthVault EOB Type (XML)

* With apps N? Y N Y Y Y

Intuit Health Expense Format (?) ? ? ? ? ? ? ?

Embedded 835 (proposed) Y Y Y Y

NCPDP D.0 Y Y Y

Others? (Please propose)

Potential Blue Button Download Delivery Patterns for Patient/Member Portals

PayerClaims

Database

Patient / Member Portal

.PDFASCII .XLS?

.XML?

Self-Displaying Embedded

Data?

Proposal: Embedded Interoperabilityin a Human-Readable File

Examples

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

JSON-in-HTML 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

Self-Contained Human-ReadableInteroperability Standards from EMR & HIE world

.XMLCDA

documentwith CSS

instruction

CSS Style Sheet+

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

XDM IHE StandardCross-Enterprise Document Media Interchange http://wiki.ihe.net/index.php?title=Cross-enterprise_Document_Media_Interchange

.zip file container

Index.html

Readme.txt

IHE_XDM folder

SUBSET folder

DOC.xml

META DATA.xml

.xslStyleSheet

Design Challenge 2012http://healthdesignchallenge.com

Visual Design for Consolidated CDA

…

ABBI Payer WG standard will pave the way for designers to run the same play for payor data, e.g. X12 835-based data

EligibleAPI: Example of Bridge betweenModern JSON API developers & EDI

Information you can call:• Patients Active VS Inactive Status• Coinsurance• Copayment• Deductible• Health Spending Balance• Speciality Specific Info (ie MRI, Diagnostic

Labs)

X12 EDI 270/271 SampleEligibility Transaction

***N~MSG*Genetic Testing~EB*H*IND*82***23******N~MSG*Genetic Testing~EB*F*IND*42***23***DY*120**Y~EB*F*IND*42***23***DY*120**N~EB*A*IND*75*****0*S7*17**Y~MSG*Hearing Aid~EB*A*IND*75*****0*S7*17**N~MSG*Hearing Aid~EB*A*IND*80^68*****0****Y~EB*A*IND*62*****.2****Y~III*ZZ*23~EB*B*IND*62***26*0*****Y~III*ZZ*23~EB*C*IND*62***26*0*****N~III*ZZ*23~EB*A*IND*81*****0****Y~MSG*Adult Preventative Care~EB*A*IND*81*****.4****N~MSG*Adult Preventative Care~EB*A*IND*A9*****.2****Y~MSG*All Therapies~EB*H*IND*A9***23******Y~MSG*All Therapies~EB*A*IND*A9*****.4****N~MSG*All Therapies~EB*H*IND*A9***23******N~MSG*All Therapies~EB*A*IND*3*****.2****Y~MSG*Specialist Services~EB*A*IND*75*****

EligibleAPI JSON (Javascript Object Notation)

{ "health_coverage": { "current_status": "active", "description": [ "Choice Fund HRA Open Access Plus", "Carelink" ], "limitations": { "remaining": "$751", "limitations_comment": "HRA Balance" }, "deductible": { "ind_yearly": "1500", "ind_remaining": "1321", "fam_yearly": "3000",

"fam_remaining": 3000 }, "coinsurance": { "ind_percentage": ".2", "fam_percentage": ".4" }, "out_of_pocket": { "ind_yearly": "2500", "ind_remaining": "2321", "fam_yearly": "7500", "fam_remaining": "7500" } }}

Resource URLhttps://eligibleapi.net/eligibility.asp?APIkey=*****************&SearchID=1&PayerName=CIGNA&PayerID=00001&ProviderLastName=Austen&ProviderFirstName=Jane&ProviderNPI=DFJJDLJAFJD&PatientLastName=Pooh&PatientFirstName=Winnie&PatientDOB=10/17/1911&PatientMemberID=FRDJLS999

(ServiceTypeCode and Version are optional)