Stream: CARIN IG for Blue Button®
Topic: Carin BB Coverage Resource
Josh Lamb (Dec 13 2019 at 15:00):
Based upon some of the questions we had at the connectathon and discussions with @Cloud Cray there is some questions and limitations with the coverage resource.
1.) It will not be possible to use the coverage resource to determine any cost of care information, even for simple things like office visits since the amount applied toward deductible and maximumoutofpocket is not tracked.
2.) The coverage resource does not contain all of the information that can be communicated using a 271 eligibility response transaction. It will not be possible to use the coverage resource to determine procedure/device/medication/etc costs. There was talks of using the eligibility response FHIR resource to fill this gap.
3.) It does not seem that we can accurately represent an instance of coverage using the coverage resource. It may be good to include additional info in the “costToBeneficiary” collection of this resource. For example, we can indicate that there is a $25 office visit cost, but I do not see any way to indicate that the office visit cost only applies once the deductible has been met. As another example, it could be that a member receives two free office visits each year, even if the deductible has not been met. The “exception“ element seems like a good place to indicate this, but the specified valueset only allows for retired and foster care exceptions.
4.) It seems that the only way to accurately capture plan information in cases where a certain coverage policy contains multiple benefits would be to create multiple coverage resources for a single policy. For example, a medical plan will have different benefit levels for in-network vs out-of-network. There may also be different benefits that are bundled in with a policy, e.g. limited dental benefits that are included under a medical plan.
Cloud Cray (Dec 13 2019 at 15:28):
Hey, Josh! I'm putting together a write-up of findings as well.
I think step 1 is clearly defining the difference between Coverage and CoverageEligibilityResponse
Cloud Cray (Dec 13 2019 at 15:49):
Here are my impressions from the "Coverage" discussion at the Connectathon:
1. Problems
- Confusion with Semantics - "Coverage" vs "CoverageEligibilityResponse".
- "Coverage" is intended to show what might also be called "Policy Information" or "Policy Identifiers"
- "Eligibility Response" is meant to contain "Benefit Information"
- Approach/Administration
- Trying to "map" the 271 is ineffective, as the 271 has historically been inaccessible to patients.
- Additionally, most current discussions would be better centered around the Eligibility Response resource, so we may want a CoverageEligibilityResponse CARIN profile
- Instead, we should approach this from a "use-case" perspective and build to support that
- Lack of parity
- RTPBC and DaVinci both work with benefit financial data. Shared data structures should be defined as new data types or resources, and the structure of existing resources should be reevaluated
- X12-linked issues
- Service type codes are inadequate for current business needs
- Certain rules (conditions) need to be explicitly defined
- The "classes" are too much of a "catch-all" - some "classes" should be promoted to reliable key/value fields
2. Proposed Next Steps
- List out use-cases (first draft below - not sure where this should be placed for collaboration)
- Identify use-cases that contain solely existing 271 data/functionality (no additional features required)
- Evaluate resources / data structures for each of these use-cases (possibly altering where certain data is located and how it is represented)
- Create and share examples (both X12 and FHIR format) of complex cases, several of which were laid out in the proposed track
To increase participation, I'm willing to share a test "parser" tool to convert X12 271 to FHIR, allowing payers to test existing X12. We'll need a place for folks to collaborate/comment/share additional test cases
3. Use Cases
- Use-cases supported by existing X12 271 implementations (what we should focus on for now)
- Eligibility check (a user wants to identify a member's policy and verify it is active; eg, "Member XBP12345 has Aetna Gold HMO, active as of 1/1/20")
- Plan Summary of Benefits (return benefit details for a standard set of services, allowing users to compare plan details; eg, "These service are covered by BCBS Silver PPO Plans, and these are the annual deductibles")
- Policy-specific Summary of Benefits (return benefit details for a standard set of services, specific to a single member's policy; eg, current deductible/out-of-pocket max)
- Service-Specific Benefits (explicitly requested service type code)
- Use-cases that would require eligibility/benefit (X12 271) data and additional development (what we should future-proof for)
- Benefits applied to a specific HCPCS/CPT/other procedure code (instead of service type codes; Medicare supports this, but not all commercial payers do)
- Real-time cost estimates/pre-adjudication (specific procedures for a specific provider, similar to RTPBC)
- Shoppable services (cost estimate for specific service across multiple providers in a geographic area)
- Episodes for complex visits/episodes/care plans (cost estimates over multiple visits, showing how the deductible would change over time)
Cloud Cray (Dec 13 2019 at 15:49):
@josh lamb @Amol Vyas @Ryan Howells @Mark Roberts @Philips Johnson
Michele Mottini (Dec 13 2019 at 15:57):
Confused: isn't the implementation guide a standardization of what CMS BlueButton is doing now - ie allowing members to get they own explanation of benefits and coverage details? These uses cases seems completely different
Josh Lamb (Dec 13 2019 at 16:35):
@Michele Mottini regarding the usefulness of the coverage resource, I was trying to highlight ways that the coverage resource will misrepresent coverage(plan) information. Specially the CostToBeneficiary portion seems to lack needed info to accurately represent policy benefits. The CMS BlueButton coverage resource, at least for test data, has little more than plan dates and plan name.
Michele Mottini (Dec 13 2019 at 16:41):
Having just that seems OK now with CMS BlueButton (?)
Josh Lamb (Dec 13 2019 at 16:46):
@Cloud Cray great feedback. Initially, I don't think we will be ready to use the FHIR eligibility response as a replacement for the 271 but it is good to begin working toward that goal. I am very interested in the 271 parser and I am willing to help test this by comparing a coverage resource that was created through the 271 parser with a coverage resource that was created through direct FHIR mapping.
Cloud Cray (Dec 13 2019 at 17:02):
@josh lamb - I agree, there won't be anything replacing the 271 for a LONG time.
However, since the 271 is a B2B transaction for provider-to-payer exchange, this isn't really a "replacement" for the 271 - there hasn't been a standard patient-to-payer transaction before. There are various use cases where the same information contained in the 271 would be VERY useful to client apps looking to give data from payers to patients. I am proposing we take a look at those use cases -many of which are new - and "future proof" what we do now to avoid conflicts later on.
Specifically, the I don't believe the "costToBeneficiary" field - which was added between versions 3/4 - belongs on the coverage resource. Not sure if that's something that needs to be sent over to the Financial Management team or not though.
Cloud Cray (Dec 13 2019 at 17:12):
@Michele Mottini Blue Button is currently using Coverage 3.0.1 as I understand, but v4 requires this new "costToBeneficiary" field.
First of all, I am contesting that this field belongs on that resource at all. Again, may need to take that up in a different forum.
Secondly, if we DO move forward with implementing that a cost component, I want to make sure it has parity with other resources/data types that share similar information. Several other resources already represent "benefit items" in a different (and more meaningful) manner.
Finally, if we include the cost component and we have structural parity with other resources, Medicare doesn't use the same 271 format or the same "Service Types" as commercial payers. There is quite a bit of detail that will be misrepresented if we try to fit commercial plan/policy details into such a narrow definition of "costToBeneficiary", and there will likely quite a bit of data lost through mapping service types.
Before going through the headache of mapping and parsing all that, I'd like an answer on whether the "costToBeneficiary" field will be required for all payers and whether it belongs there at all.
Josh Lamb (Dec 13 2019 at 17:16):
@Cloud Cray I agree regarding CostToBeneficiary. It is not required to conform to the CARIN profile and it has not been extended by CARIN. As of now I will not be populating this since it will misrepresent the plan information.
Cloud Cray (Dec 13 2019 at 17:17):
@josh lamb My parser will likely ignore the costToBeneficiary field, and will produce a CoverageEligibilityResponse that contains a Coverage object
Josh Mandel (Dec 13 2019 at 17:20):
Just to check here, we're talking about the content in the http://build.fhir.org/ig/HL7/carin-bb/Use_Case.html IG, right? Are we discussing changing the scope / use cases supported by the draft guide, or creating a new guide for a different / broader set of use cases?
Cloud Cray (Dec 13 2019 at 17:20):
On a less important note, I worry that too much detail is going to be dumped into the "classes" array that should either be explicit fields or be moved to another resource (eg CoverageEligibilityResponse)
Josh Mandel (Dec 13 2019 at 17:21):
In particular, details like a "Coverage Eligibility Response" would seem to be an answer to a question like "how much would XX cost?" or "do I have coverage for XX"? Neither question seems like it's in-scope for the current guide (which looks to be focused on answering things like "which plan do I have?" and "what benefits have I received to-date?").
Josh Mandel (Dec 13 2019 at 17:21):
(Take my assessment as... just a scoping question, because I haven't been at the connectathon and I'm probably missing context.)
Cloud Cray (Dec 13 2019 at 17:25):
@Josh Mandel - I believe the "Use Case" needs to be updated, as it appears to only describe receiving claims data.
Talking about implementing Coverage for commercial payers:
https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-CARIN-BB-Coverage.html
My impression from the description of the Coverage resource is "what you see on your insurance card", which is effectively "Policy Identifying information" - not mutable data such as "how much of my deductible has been paid to date?"
Can you expand on what you mean by, "What benefits have I received to date"?
Michele Mottini (Dec 13 2019 at 17:28):
it appears to only describe receiving claims data
That's the blue button use case, ins't it?
Michele Mottini (Dec 13 2019 at 17:29):
but v4 requires this new "costToBeneficiary" field.
No, it is not required, it is optional - it can be omitted
Josh Mandel (Dec 13 2019 at 17:31):
Thanks @Cloud Cray (and I'm delighted that you're engaged here :-)).
Can you expand on what you mean by, "What benefits have I received to date"?
Here, I just meant "Let me access my ExplanationOfBenefit resources".
Josh Mandel (Dec 13 2019 at 17:32):
In other words, initial scope for the guide was: EoBs, and what you described nicely as "Policy Identifying Information." Are we contemplating expanding scope for v1 of the IG?
Cloud Cray (Dec 13 2019 at 17:34):
I don't think so @Josh Mandel - this "costToBeneficiary" field was causing some confusion. If we are allowed to ignore it, I don't think there's an issue
Cloud Cray (Dec 13 2019 at 17:40):
However, I think if we're going to ask all the payers to start mapping the 271 data into consumer-facing resources, it would be wise to think ahead at other use cases that would utilize that data. Doesn't necessarily mean we'd alter v1 - although we might explicitly recommend avoiding implementation of costToBeneficiary if we think there's a chance it will be used somewhere else
Josh Mandel (Dec 13 2019 at 17:45):
That certainly makes sense to me.
Philips Johnson (Dec 13 2019 at 20:16):
@Cloud Cray - Great write up of the conversations we had. Let me know how I can help moving forward
Paul Knapp (Dec 16 2019 at 18:04):
Hi All. It would help the discussion if participants are able to attend Financial Management work group calls (Tues 11AM Eastern) or join the committee meetings at WGMs.
The Coverage resource is intended to convey card level information, not for requesting eligibility (EligibilityRequest and EligibilityResponse are the corollary to the X12 270/271) or for detailing all of the policy specifics or table of benefits. In the US, WEDI has a published health insurance card guide which details the standard attributes including [optionally] co-pay, deductible, urgent care etc. rates - the intention of costToBeneficiary is to hold those latter elements, and the Coverage resource supports recording those elements specified in the WEDI guide.
Last updated: Apr 12 2022 at 19:14 UTC
