Stream: CARIN IG for Blue Button®
Topic: CPCDS EOB Data Fields
Christopher Marchand (Jun 08 2020 at 14:39):
Hi team - what field in the CPCDS EOB file would represent the main billing code or visit type (i.e. medium complex office visit)?
Christopher Marchand (Jun 12 2020 at 15:56):
@Amol Vyas any insight on the above ^ ? I do not see any field representing this in CPCDS EOB.
Amol Vyas (Jun 14 2020 at 21:14):
Christopher Marchand said:
Hi team - what field in the CPCDS EOB file would represent the main billing code or visit type (i.e. medium complex office visit)?
Amol Vyas any insight on the above ^ ? I do not see any field representing this in CPCDS EOB.
Hi Christopher, per the type (profile) of the adjudicated claim/EOB, I believe you will find this information in one of couple of profile structures.
- For institutional/facility (inpatient/outpatient) claims - Type Of Bill (Type Of Care sub-field). Note that Type Of Bill structure will be consolidated into one field in the upcoming update to the IG.
- For professional/non-clinician claims - Procedure Codes (CPT/HCPCS Level 1, 2)
For more information, the current IG page and the May FHIR Connectathon CARIN BB track's latest materials page, list the a) CARIN BB profile mapping and b) CARIN BB profile comparison in the their current and updated versions, respectively. We will be deploying these and other updates that are approved as part of the IG's HL7 ballot reconciliation process so far to the build environment soon.
@Pat Taylor , @MaryKay McDaniel : Please feel free to validate above.
Christopher Marchand (Jul 16 2020 at 13:48):
@Amol Vyas, @Pat Taylor , @MaryKay McDaniel Do you have a date when you will have the IG updated with the latest mapping documents and specs? I am struggling to follow all the changes and notice that there are conflicting materials on different pages and sources which is making development complicated.
Pat Taylor (Jul 20 2020 at 14:53):
The mapping document and specs should reflect the one dated May 15th. The next published version will include the May 15th version. We are working on another update and are targeting completing it within the next two weeks. The most current version is attached to JIRA-26741 @Amol Vyas @MaryKay McDaniel @Saul Kravitz @Mark Roberts
Kate Dech (Jul 21 2020 at 19:12):
@Pat Taylor , @Amol Vyas , @MaryKay McDaniel , @Saul Kravitz , @Mark Roberts - Can you also update the CPCDS Mapping spreadsheet that is published on the CARIN Confluence page? I have been using that as the guide so it's good to know that there is a more recent version - and one soon to follow in a few weeks.
Also I have specific questions about the adjudication amount type categories from the original mapping to the 0513 version.
- There had been a category code for Allowed. That isn't in the current set. Is Eligible to be used in it's place?
- There had been a category code for Payment (generically to represent the total, not the split out between payment to provider and payment to patient). Is Benefit to be used in its place?
- You still have PaidByPatient and in the IG the definition is "The amount paid by the patient at the point of service." That is a very different description than what I see in the Data Element Index of the mapping artifact. That description is more about what the payer determined the total member responsibility: "Amount that is calculated by the processor and returned to the pharmacy as the total amount to be paid by the patient to the pharmacy; the patient’s total cost share, including copayments, amounts applied to deductible, over maximum amounts, penalties, etc." My business cohorts think this desciption more aptly fits Member Liability. Can we get clarification on the Data Element Index and IG Code Definitions which Code should be used for "Amount that is calculated by the processor and returned to the pharmacy as the total amount to be paid by the patient to the pharmacy; the patient’s total cost share, including copayments, amounts applied to deductible, over maximum amounts, penalties, etc."?
cc: @Bapi Behera, @Mona O
Kate Dech (Jul 22 2020 at 22:13):
By the way, I do want to acknowledge what a fabulous job you guys did with the profile+the CPCDS mapping. Not only do we know the structure, but where to put the data in that structure. Please don't misinterpret my questions about the minutiae as criticism! To me it shows you guys nailed the basics!! And I'm able to get into the nitty-gritty details because of it.
Kate Dech (Jul 22 2020 at 22:16):
That said, I do have another nitty-gritty question (sorry!). eob.supportingInfo.sequence. On the pharmacy profile, you have some named slices always setting the sequence = 1. And then some say "reference supportinginfo.sequence rule." What is this rule? I would have assumed each supportingInfo array would get a unique number - slice name or no slice name. Thoughts?
Pat Taylor (Jul 28 2020 at 19:20):
Hi Kate, Thanks for the compliment! No problem with the questions.
1: Yes, allowed has been changed to eligible; we've standardized on a term HL7 had previously defined.
- Benefit is different from the payment to the provider or patient as it will include the deductible, co-pay and co-insurance payable by the patient to the provider. The payer will typically pay either the provider or the patient.
- The amount paid by patient is different for medical and pharmacy claims. For medical, it is the amount paid by the patient at the point of service and typically represents a co-pay. Retail pharmacy is typically a point of service transaction; the member liability is what is paid by the patient as they purchase the prescription.
- The supportinginfo.sequence rule is in the Rules tab. It states that client app implementations should look up supportingInfo elements based on the category values instead of the sequence rules. May I get back with you to answer your question why some of the sequences call out a value = 1 and others call out the rule? @Amol Vyas @MaryKay McDaniel @Saul Kravitz @Mark Roberts @Bapi Behera @Mona O
Pat Taylor (Jul 29 2020 at 18:41):
Hi again Kate, good catch on the question about the sequences! .. all should call out the rule. We've updated the worksheet; the updates will be reflected in the next published version. Pat
@Amol Vyas @MaryKay McDaniel @Saul Kravitz @Mark Roberts @Bapi Behera @Mona O
John Achoukian (Aug 11 2020 at 18:35):
Hello - This is John Achoukian from HealthTrio. I am new here.The JSON examples we see on the http://build.fhir.org/ig/HL7/carin-bb/Examples.html site for EOB profiles provide a ‘total’ element that is ‘not mandatory’ nor ‘must support’. The JSON examples do not include ‘item’, ‘adjudication’, or ‘payment’ elements which are all indicated as ‘must support’. Our client maintains ‘billed amount’, ‘allowed amount’, and ‘paid amount’ at both the claim and claim line item level. Can you provide some direction as to what EOB resource elements must be populated?
Michele Mottini (Aug 11 2020 at 18:48):
The ones with min cardinality = 1
Ryan Howells (Aug 13 2020 at 02:50):
Hi @John Achoukian Our team can help. We're making a few updates to the examples. @Amol Vyas @Saul Kravitz
John Achoukian (Aug 13 2020 at 18:15):
Thanks @Ryan Howells @Amol Vyas @Saul Kravitz - We are looking forward to updated examples and any additional guidance on what EOB resource elements must be populated, especially instances where we have financial (billed, allowed, paid) data at both the claim and claim item level.
Bryan Briegel (Apr 21 2021 at 16:03):
Hi Pat - in review of these comments, we have resolved that eligible is allowed, though we had been thinking benefit would have been the candidate. Interrogation of the examples in the C4BB IG, show benefit and eligible always hold the same value. In reading above, it almost looks like benefit is/may be a larger value than eligible, as it appears benefit is not 'net down' of not covered and discount amounts. Would you have an example where benefit and eligible might be different amounts, and what would another name for benefit be? (eg eligible == allowed) - thank you! @Pat Taylor
Last updated: Apr 12 2022 at 19:14 UTC
