Stream: implementers
Topic: Health Insurance
Luan Garrido (Mar 08 2018 at 03:30):
Does anyone know how health insurance (medical plan) are modeled in FHIR v.3.0.1?
Lloyd McKenzie (Mar 08 2018 at 03:33):
Look at the Coverage resource
Cloud Cray (Mar 22 2018 at 17:00):
I actually would like to address a shortcoming of the current design - the "Coverage" resource currently doesn't actually define insurance coverage. It currently specs out details for Policy Identifiers (subscriber id, etc) and Insurance Plan identifiers ("Blue Cross Silver PPO") and a few additional attributes, but doesn't actually have a place for "What is and isn't covered" - only whether the policy is active or not.
I think the Coverage resource needs to be reworked, along with the Eligibility resources. I would advocate that there is a distinction between an "Insurance Plan" and an "Insurance Policy".
An InsurancePlan, such as "Blue Cross Blue Shield Silver PPO", has information that does not change between patients.
An InsurancePolicy, on the other hand, has information unique to a policy holder, such as patient/subscriber demographics, whether that plan is active, what the current deductible remaining is, etc.
The Insurance Plan also has "coverage information" that should not change between policyholders - basically anything that would be defined on the blue summary PDF all plans are required to have.
The Insurance Policy would inherit all of the same information, along with the "current status" of the dedcutible/out-of-pocket maximum, etc that is unique to the policy holder.
The ACA established reporting criteria for payers on any plans they offer, so the data is available and is being used regularly. The largest public repository of this plan information is the CMS HIOS page, if you want to take a look. I would propose that all of the data required to define an insurance plan should be abstracted into an insurance plan resource.
Some of the coverage/benefits information is defined on the EligibilityResponse at the moment, but that was designed with the assumption that the financial information would only be attached to individual policies - it doesn't address that much of this data is "attached" to the insurance plan. The EligibilityResponse needs a lot of work as well to have full parity with the 270/271 eligibility data being used by health systems today.
Cloud Cray (Mar 22 2018 at 17:01):
Not 100% sure if this is the right place to raise the issue - going to join the Financial Management committee call later today and see if this and a few other concerns can be addressed
Lloyd McKenzie (Mar 22 2018 at 20:46):
The argument to date has been that Coverage is used when communicating to the payor/insurer who knows what's covered, so there's no need for the Coverage resource to expose that. However, given that Coverage is also passed around between purely clinical entities, I tend to agree that Coverage should surface what's covered. Discussing on the FM call is appropriate. You can also raise a change request and, if you wish, can participate in the upcoming ballot.
Cloud Cray (Mar 22 2018 at 23:31):
Thanks - got on the call today and we clarified some things. The current "Coverage" object is meant to only contain identifying information for a patient's insurance policy, and the eligibility request/response is meant to be more like a "prior auth", tied to an explicitly requested service rather than a "plan overview". There is no resource meant to show a plan or policy overview. Going to collect some thoughts and send to the FM listserve
Paul Knapp (Mar 25 2018 at 09:36):
Sort off. The Coverage is intended to convey the identification of a Policy/Plan, essentially the card details, between providers or from a provider to an insurer. The ProductPlan resource under development contains what you are referring to as Plan information above. The EligibilityResponse (and the ExplanationOfBenefit) conveys policy definitional and current balance information, and the EligibilityResponse can also indicate if a coverage is in-force, provides benefits for a class and subclass of products/services (medical, vision, dental subclass orthodontics) and whether pre-authorization is required for a suite of proposed products/services.
The Contract resource is the current option for the Policy however we want to finalize the information requirements and usage before committing to where this information is held and from where it is referred.
David Teirney (Mar 27 2018 at 02:22):
@Cloud Cray what was the outcome of the thoughts that you sent to FM? I don't fully understand why Coverage (or something) shouldn't be used to provide what appears to be reasonably standard information regarding what the Coverage plan is and the benefits that it covers. The CMS BlueButton FHIR Coverage implementation also has a number of extensions as well (that I've yet to go through in detail). https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/Blue-Button/index.html
The Eligibility request/response model doesn't seem to fit our use case well. We already hold much the coverage information and are looking for a way to expose it via an Open API so other systems (like a HEDIS measure calculation engine) can make use of it.
Having typed all that, the new ProductPlan domain resource exposes much more of what I am trying to find a home for. http://build.fhir.org/productplan.html. How will that content actually be exposed through a resource?
Cloud Cray (Mar 27 2018 at 20:00):
I think the ProductPlan will capture a lot of the information I'm looking for as well. Still looks like it's under development, esp with the "Benefit" structure being in 2 places, and without clear parity with the EligibilityResponse object.
Now I'm getting worried about semantics. The "Coverage" resource contains identifying information for a policy. The "ProductPlan" contains a "coverage" attribute that is not a Coverage object. Will address on the call this week.
Cloud Cray (Mar 27 2018 at 20:57):
I don't think there's a proper 1:1 resource that handles the 271 response yet. The ProductPlan is a description of coverage, but isn't tied to a patient/policyholder. The EligibilityRequest/EligibilityResponse seems more like, "How is this service for this provider covered?", almost like a preauth or something.
I think there needs to be a "What is the current status of my Policy, and what does it cover?" resource, like the 270/271 currently answers.
David Teirney (Mar 28 2018 at 02:38):
Agree that it would be good to have a "What is the current status of my Policy, and what does it cover?" resource.
The following feels like it makes sense to me based on my involvement with these domains so far. A patient has one more Coverage records (through the beneficiary reference). Each Coverage would reference a specific ProductPlan offered by a Health Insurer. Each ProductPlan defines the benefits associated with that plan (patient/member agnostic).
Cloud Cray (Mar 28 2018 at 12:48):
This was my explanation of the different use cases as I see them, and the different needs associated with them:
https://www.youtube.com/watch?v=46jqE--02tE
^ @David Teirney does this cover your concerns?
Paul Knapp (Apr 03 2018 at 11:33):
They purpose of the Coverage resource is to provide the patient, coverage type and identifiers for billing purposes. This is information which is provider to the insurer in claims and other inquiries and exchanges and provided to other providers, during referral and other activities, to reduce their data entry.
The 'what does the plan cover and how much has the patient consumed' are the 'benefits', not the coverage, and while they have often not been conveyed electronically we are working on the provision of that information either in the context of existing exchanges, eg EiligibilityResponse and ExplanationOfBenefit. The ProductPlan resource similarly contains Plans - which identify a named (and identified) suite of benefits provided by an insurer - for the purpose of allowing one to identify potential plans to purchase or conversely to identify what services may be preferentially reimbursable or which networks of providers may be preferable for referring patient for treatment.
Lloyd McKenzie (Apr 03 2018 at 17:00):
Coverage isn't only used when communicating to insurers. It's also used when communicating between providers - it's common for coverage information to be gathered by one provider and then communicated to other downstream providers.
Eric Haas (Apr 03 2018 at 22:49):
@Cloud Cray that was a nice youtube presentation that helped me a understand a lot of issues. In the Argonaut Scheduling IG we scratched the surface of exchanging the basic coverage info that is printed on a patients insurance card and have on our wish list the projected out of pocket expense. So I am glad you brought that up - I wonder if that could be a patient facing hook.
Paul Knapp (Apr 04 2018 at 06:52):
@Lloyd McKenzie Correct, that's why I wrote 'and other inquiries and exchanges and provided to other providers'.
David Teirney (Apr 04 2018 at 12:13):
Coverage information for the associated benefits is necessary for a number of HEDIS 2018 measure calculations. I'd initially started looking at the work being done in http://build.fhir.org/ig/cqframework/hedis-ig/ for guidance on where I should look to expose content for a HEDIS calculation engine that would be looking to use CQL for the measure definitions. I found that the profiles done at that point in time (it's a work in progress after all) didn't identify some of the fields needed for some of the measures we have implemented so far (or information for the resulting reports that need to be submitted). ProductPlan looks like it could be heading in a direction that would cover some of the reporting aspects that, at the time, I didn't find a clear home for, e.g. for what NCQA refers to as product lines (Medicare, Medicaid, Marketplace or Commercial), products (HMO, PPO, POS, EPO, FFS), benefit packages (DSNP, ISNP, Chronic Condition, LTI), benefits (Chemical Dependency, Dental, Hospice, Medical, Mental Health, Outpatient, Pharmacy, Vision).
For the coverage/benefit/product related resources to be useful for a number of our future use cases, the resources would ideally expose information in a way such that that analytics type queries could be defined using CQL to access the "point in time" representation of that information. I'm not sure how some of the request/response type resources would work in that scenario.
HEDIS clinical quality measure calculations appear dis-interested in anything related to billing other than was the claim paid or denied.
Paul Knapp (Apr 08 2018 at 09:02):
@David Teirney Are you wanting point in time information on the suite of benefits available under all coverages for a patient or do you also want what they have consumed of those benefits at that point in time? If the later that would require that an EligibilityRequest be issued for each coverage at that point in time, assuming the insurers all respond with benefit and consumption details. There is no resource which provides real-time tracking of benefits and consumption, outside of the insurer themselves, and currently no use case for a benefits and consumption as at a date request.
Any exchange of consumption to-date or effective balance remaining as at a target date would require the broad participation of the insurance industry and they are likely to weigh the risks and benefits of doing so before agreeing to provide that information to parties other then the patient or subscriber. Similarly a credit card processor will only tell a vendor if the purchasers cad has sufficient funds/capacity for the indicated purchase amount but will not tell that same vendor the total debit or credit balance or amount available.
David Teirney (May 07 2018 at 04:15):
@Paul Knapp just the information about the benefits available for all coverages for a patient. Typically the measure calculations are run some time after claims were submitted although we're looking to get closer to real-time. So, it's necessary to get the historical benefit information, e.g. vision was covered from X to Y in time. Typically there are only changes to benefits through a coverage being stopped and a new coverage starting with the new benefits (typically due to a product change). The clinical quality measures we've implemented thus far don't need anything relating to the actual consumption of benefits.
David Riddle (May 10 2018 at 22:13):
ProductPlan looks like it could be heading in a direction that would cover some of the reporting aspects that, at the time, I didn't find a clear home for, e.g. for what NCQA refers to as product lines (Medicare, Medicaid, Marketplace or Commercial), products (HMO, PPO, POS, EPO, FFS), benefit packages (DSNP, ISNP, Chronic Condition, LTI), benefits (Chemical Dependency, Dental, Hospice, Medical, Mental Health, Outpatient, Pharmacy, Vision).
@David Teirney ProductPlan.coverage.type (Medical, Dental; Mental Health; Substance Abuse; Vision; Drug…) seems like a good fit for NCQA 'benefits' and ProductPlan.coverage.benefit.type (primary care; specialty care; inpatient; outpatient) might work for NCQA 'benefit packages'; however, I don't see any obvious elements intended to convey things like the NCQA 'product line' (Medicare, Medicaid, Commercial…) and 'product' (HMO, PPO, POS…) concepts as you describe them. Am I missing something? i.e., Are there existing elements on the ProductPlan resource that you would expect to use for these concepts?
David Riddle (May 14 2018 at 16:57):
@Paul Knapp, under ‘8.34.1 Scope and Usage’ the ProductPlan resource defines a product as ‘a discrete package of health insurance coverage benefits that are offered under a particular network type’. By ‘network type’ is this referring to concepts like HMO, PPO, POS, EPO… or something else? Regardless, what element on the ProductPlan resource will convey the network type associated with the product?
On a somewhat related note, the PHDSC Source of Payment Typology standard [1] seems to merge some of the NCQA measure reporting concepts @David Teirney has reference here. At the lowest level of the Source of Payment Typology hierarchy, there are code values [2] that appear to convey a combination of the NCQA product line (Medicare, Medicaid, Commercial…), product (HMO, PPO, POS…) and benefit (Medical, Dental, Drug…) concepts and would facilitate the types of stratification called out in the NCQA documentation. For example:
111 ‘Medicare HMO’ – This typology code conveys a managed Medicare ‘product line’, HMO ‘product’ and Medical ‘benefit’
511 ‘Commercial Managed Care HMO’ – This typology code conveys a Commercial ‘product line’, HMO ‘product’ and Medical ‘benefit’
516 ‘Commercial Managed Care Pharmacy Benefit Manager’ – This typology code conveys a Commercial ‘product line’ and Drug ‘benefit’
I saw your comments [3] regarding where to put some of these NCQA concepts on the FHIR Coverage resource. e.g., ‘in a US profile on Coverage you may place: product line (Medicare, Medicaid, Commercial, Marketplace…) in Coverage.type’ However, I am not sure if/where these same concepts map to the FHIR ProductPlan resource. For instance, the examples currently associated with ProductPlan.coverage.type element (Medical, Dental; Mental Health; Substance Abuse; Vision; Drug…) seem to align better with the NCQA benefit concept than the NCQA product line concept.
[1] http://www.phdsc.org/standards/pdfs/SourceofPaymentTypologyUsersGuideVersion7FinalJune27_2016.pdf
[2] http://www.phdsc.org/standards/pdfs/SourceofPaymentTypologyVersion7FINALJune27_2016.pdf
[3] https://chat.fhir.org/#narrow/stream/4-implementers/subject/Help.20with.20where.20to.20put.20coverage.20information
Last updated: Apr 12 2022 at 19:14 UTC
