FHIR Chat · Help with where to put coverage information · implementers

Stream: implementers

Topic: Help with where to put coverage information


view this post on Zulip David Teirney (Mar 26 2018 at 04:28):

Hello, I'm trying to determine where some reasonably standard content would typically appear in the FHIR Coverage model. This information is needed for HEDIS calculations so we're looking for guidance on where this information should be exposed via the FHIR domain model.

Using NCQA terminology:
1) Where would product line information typically be exposed, e.g. Medicare, Medicaid, Commercial, Marketplace?
2) Where would product information typically be exposed, e.g. HMO, PPO, EPO?
3) Where would benefit package information be exposed, e.g. Special Needs Plans such as DSNP, ISNP?

Some related coverage fields but not specifically for HEDIS.
4) Where would the metal level be exposed for Marketplace coverage, e.g. Bronze, Silver, Gold or Platinum. (https://www.healthcare.gov/choose-a-plan/plans-categories/)

I've already noticed that actual benefit information isn't exposed by Coverage, e.g. vision, dental, hospice, chemical dependency etc, but in my mind probably should be otherwise I'm not sure how a client system would know what benefits a given coverage includes to help support HEDIS measure calculations.

view this post on Zulip Lloyd McKenzie (Mar 26 2018 at 14:17):

My understanding is that a new resource is planned for this, though I would expect at least some of it should be exposed in Coverage. When passing data between clinical systems, having just the bare identifiers isn't much use if you don't know what type of coverage the identifiers are tied to. @Paul Knapp ?

view this post on Zulip Paul Knapp (Apr 03 2018 at 11:47):

@David Teirney @Lloyd McKenzie The Coverage resource intentionally contains the identifiers and not the 'benefits' as this is historically what is required to enquire about or seek authorization or reimbursement under an insurance policy.
Historically most insurers do not provide the benefit information or consumption to-date electronically, but some are and do in certain circumstances (Eligibility, EOB) so the various resources contain means to convey that information.
In FHIR we try to contain within resources as elements those concepts which are more universal in nature - although the specific vocabulary by be set by jurisdiction in a jurisdiction profile (IG), and in extensions where the concept is of limited use. I in a US profile on Coverage you may place: product line in Coverage.type and the HMO/PPO, DSNP/ISNP and metal level would either be Coverage.Class instances or extensions.
We are exploring both Contract and ProductPlan to hold benefits, although the latter would not be suitable for to-date consumption.

view this post on Zulip Lloyd McKenzie (Apr 03 2018 at 17:03):

It's not a question of what the insurers provide, it's a question of what the EHR and other clinical systems store and pass around to other clinical systems. The information on Coverage needs to be sufficient to meet the business needs of the clinical systems when they're looking at the patient record and determining what type of insurance the patient has. Whether that information comes from the insurer electronically or in paper form or over the phone or is relayed by the patient doesn't matter. Once it's in an EHR, it'll be passed around elecronically from that point forward.

view this post on Zulip David Riddle (Jul 03 2018 at 13:54):

@Paul Knapp
You indicated ‘in a US profile on Coverage you may place: product line in Coverage.type and the HMO/PPO, DSNP/ISNP and metal level would either be Coverage.Class instances or extensions’; however, Coverage.type has a terminology binding to Coverage Type and Self-Pay Codes [1]. That valueset does not appear to include any explicit/specific Medicare, Medicaid, Commercial… (‘product line’) concepts, but does include HMO, PPO and POS (‘product information’) concepts. Would Coverage.type vs. Coverage.class be a better fit for the NCQA ‘product information’ concepts? If so, do you still see Coverage.type as the right place for the NCQA ‘product line’ (Medicare, Medicaid, Commercial, Marketplace…) concepts?

[1] http://build.fhir.org/valueset-coverage-type.html

view this post on Zulip Eric Haas (Jul 03 2018 at 17:15):

I think what you are looking for is covered in the draft ProductPlan resource?

view this post on Zulip Paul Knapp (Jul 05 2018 at 11:28):

@David Riddle Can you attend next weeks FM conference call to discuss this?

view this post on Zulip David Riddle (Jul 05 2018 at 14:56):

@Paul Knapp I can attend next week's FM conference call ( 7/10/2018 @11:00 AM Eastern).
That will be the first HL7 conference call I have participated in, so I might need some guidance/coaching on how best to raise the topic.

view this post on Zulip Paul Knapp (Jul 11 2018 at 11:27):

@David Riddle Hi David: My apologies for missing yesterdays FM call but I will be on the call next week and did review the issues raised with Mary Kay. The Coverage.type would be the right place to hold a code related to the type of insurance. I am thinking, perhaps incorrectly, that you have two kinds of information you wish to capture so I'm not sure of the nature of that 'other' information such that I can correctly advise on how it should be handled. I would appreciate if you can make it to next weeks call and we can sort out your needs.

view this post on Zulip Brian Postlethwaite (Jul 11 2018 at 11:40):

The new ProductPlan resource (soon to be renamed InsurancePlan) holds the practitioner catalog of plans, not any consumer/patient specific details

view this post on Zulip David Riddle (Jul 11 2018 at 17:40):

@Paul Knapp No worries Paul. Everyone on the FM call was very helpful.
That said, I do think it would be good to discuss the 'two kinds of information' (Medicare, Medicaid, Commercial…/'product line’ in NCQA terminology & HMO, PPO and POS.../‘product information’ in NCQA), since Coverage.type only supports a single entry. Unfortunately I have schedule conflicts on 7/17 & 7/24. Could we discuss it on the 7/31 call?

view this post on Zulip Paul Knapp (Jul 12 2018 at 11:11):

@David Riddle Yes!

view this post on Zulip MaryKay McDaniel (Jul 13 2018 at 01:15):

@PaulKnapp @BrianPostlethwaite @David Riddle
We really need to talk about all of these.
The code sets and the terms used are going to cause some interesting commentary:
What does /what is an InsurancePlan???
In the US there is state regulation that defines "Types of Insurance" - i.e., Automobile, Health, Homeowner/residential, Life & Annunity, LTC, Pet, Worker's Compensation
There is also Federal Regulation that defines Plan Type, i.e., HMO, PPO, EPO, POS, HDHP, CP
Then there is the whole discussion of Product line: Medicare, Medicaid, Commercial (Private) which started this thread,
And don't let us forget the metal level discussion which is really about how much (on average) I'm responsible for, 10-20-30-40%
AND head down the path of Special Need Plans - Medicare and Medicaid - but what about all the county specific plans???

I'd love to have a larger industry discussion and then come back to map/develop and ... write it all out???
it appears we need to look at several resources: Coverage, Eligibility, Contract and the new InsurancePlan.

thanks!
MK

view this post on Zulip David Riddle (Jul 13 2018 at 13:45):

@MaryKay McDaniel +1

Just some ‘food for thought’… For whatever it is worth the Public Health Data Standards Consortium (PHDSC) Source of Payment Typology [1] contains codes that seem to ‘pre-coordinate’ some of these concepts. e.g. 111 = ‘Managed Medicare HMO’, 511 = ‘Commercial Managed Care - HMO’, 512 = ‘Commercial Managed Care – PPO’…

The PHDSC Payer Typology Sub-Committee appears to have lobbied [2] to replace the existing X12 Claim Filing Indicator codes employed in X12 837 and 835 transactions with the Source of Payment Typology codes. I think they make some good arguments [2] for why the existing Claim Filing Indicator concepts are inadequate for some use cases.

[1] http://www.phdsc.org/standards/pdfs/SourceofPaymentTypologyVersion7FINALJune27_2016.pdf
[2] http://phdsc.org/standards/pdfs/The_Source_of_Payment_Typology_X12Presentation_September2015.pdf

cc @Paul Knapp

view this post on Zulip Paul Knapp (Jul 13 2018 at 14:38):

@David Riddle @MaryKay McDaniel Makes sense, we should consider.

view this post on Zulip MaryKay McDaniel (Jul 13 2018 at 15:23):

@paulknapp, @David Riddle
I'll put a score card together for the call on the 31st


Last updated: Apr 12 2022 at 19:14 UTC