What ABBI can for for Healthcare Cost Transparency

I've been having some discussions with several members of the Claims Attachments workgroup in HL7 as a result of some of the conversations about Content in the #ABBI project.  One of the observations a couple of weeks back was that while we have several candidates for clinical content, there is nothing for administrative content.

I suspect we can change that pretty quickly, and there are at least two initiatives being discussed in HL7 on that front.  The first of these is to create a simple CDA Implementation Guide that describes a set of templates for an Explanation of Benefits (EOB) form.  This is the piece of paper that you get from the insurance company that usually starts with: "This is not a bill".

I have stacks of these pieces of paper at home from numerous insurers over the years filed in several boxes, and am going to start digging them out.  My hope is to build an implementation guide that will support access to these using the ABBI PULL or PUSH protocols.  Patients would be able to sign up with their payers to have their EOB statements sent to them electronically and securely.

Just as will other content being exchanged, they could request the content to be in text/html, text/plain, application/pdf or text/xml.  The text/xml format would be the "root" of all these formats (as I will also propose for clinical content).  When the content is in text/xml it will be CDA.  For administrative content, this would be the CDA specified by the new guide.  When the content is text/html, it is a simple transformation from CDA narrative blocks to HTML [I have several of these, one which I consider to be the canonical HTML transform of CDA].  When the content is text/plain, it is a different transform producing simple ASCII text.  And finally, if I get to it, application/pdf will be a PDF rendering of the text/html content, as generated when run through an XSL:FO processor that generates PDF from HTML content.

The text/xml content will contain the following data elements:

• Insurer Information (National Payer ID, Name, Policy information)
• Patient Information (Identifier, Name, Address)
• Provider Information (National Provider ID, Identifier, Name, Address)
• A table containing rows for each diagnosis:
• Diagnosis
• Service Performed
• Date(s) of Service
• Price Billed
• Negotiated Price
• Amount Paid
• Patient Responsibility
• Notes

This is not hard for me, and I think it could also be pretty easy for payers.

Many payers can already generate application/pdf for patients, and make them available electronically but this will make it even easier for payers:

1. They'll be able to use OpenID, OAuth and TLS to ensure compliance with HIPAA
2. Communication mechanisms will be the same for all payers, enabling patients to gather data using applications (e.g., from their smart-phone).
3. I expect that a standardized infrastructure will be cheaper for payers than every one of them doing the same thing differently.

What can patients do with this data?  Well, not only will they 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.  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:

1. For a given diagnosis and plan, average costs for services and providers in their region.
2. For given diagnoses, the expected annual out-of-pocket costs for providers that the patient uses, based on historical data.

No such aggregator exists today.  However, supporting such content would enable such a business.

Already, one other person I've talked to is looking at creating a FHIR profile of this content.  That's probably the best content to go with long term.  However, most payers move slowly.  It's been hard enough to get them away from disco-era EDI transactions and using XML.  CDA is something they are starting to understand.  But if enough of them like application/json, I certainly won't stand in their way.  As a green field, this one is ripe for FHIR if we can get the uptake.

The upside for payers is that access to such data across payers will enable them to drive costs downward.  They are just as handicapped as patient's are with respect to understanding "what the market will bear" when prices are only determined after claims have been adjudicated.  The downside is that same data can be used to price shop different payers and different plans within a single payer.

Who's up for this project?

-- Keith

P.S. In looking for the link explaining the "Genius of the AND" in 2012, I realized I never finished that post.  It's based on a simple question Doug Fridsma asked me "Why Not Both?"  To which John Moehrke responded brilliantly:  "There's no reason.  In fact, FHIR, MHD and hData let you ask for the kind of content you want."