Stream: CARIN IG for Blue Button®
Topic: EOB - Pro/Out/In - Varying Must Support, Cardinality, etc
Mark Rogers (Dec 02 2020 at 20:47):
I've noticed some differences between the EOB Professional, Outpatient-Institutional, and Inpatient-Institutional profiles outside of the variances a billing-novice like myself would expect (e.g. admissionperiod is only listed as 'must support' for Inpatient).
I used red text to highlight the odd-one-out, except for cases where it was a 1v1 comparison.
Codes & Types
image.png
Cardinality
image.png
Must Support Flags
image.png
Would appreciate folks letting me know if some of these elements should indeed be different across the profiles, vs what might be something that can be updated.
Saul Kravitz (Dec 02 2020 at 20:56):
@Pat Taylor
Hi @Mark Rogers -- focus on fields that are MS. The example value sets you've identified are on fields that are not MS, so the profiles don't specify a binding (and the base resource has an example binding).
Mark Rogers (Dec 02 2020 at 21:07):
@Saul Kravitz - Thanks, that does make sense, I do now see that Inpatient profile's MS flag is the differentiator for the careTeam.qualification, procedure.type, and procedure[x] bindings.
What do you think about the MS flag & cardinality differences?
Saul Kravitz (Dec 02 2020 at 21:38):
They are all by intent, based on the properties of the different EOBs. The best side-by side comparisons are here -- http://hl7.org/fhir/us/carin-bb/STU1/Common_Payer_Consumer_Data_Set.html
I also recommend reviewing the notes on each profile, which should provide insight into the mysteries of billing. See for example: http://hl7.org/fhir/us/carin-bb/STU1/StructureDefinition-C4BB-ExplanationOfBenefit-Inpatient-Institutional.html#notes-on-fields
Mark Rogers (Dec 02 2020 at 22:16):
Reviewing those documents (before I created the initial post), I didn't see the kind of nuance to clear up my confusion.
Just for an example, what about the processNote.text? I didn't see anything in the CPCDS or profile notes about why it is MS for Inpatient-Institutional and Outpatient-Institutional, but is not MS for Professional.
Saul Kravitz (Dec 02 2020 at 22:25):
@Pat Taylor
Saul Kravitz (Dec 02 2020 at 22:27):
@Mark Rogers -- didn't mean to imply that you hadn't read the notes. Apologies. As a billing-naive person, I found the notes and the comparison chart illuminating.
Mark Rogers (Dec 02 2020 at 22:31):
No worries, I think we're in the same boat!
MaryKay McDaniel (Dec 03 2020 at 16:30):
Morning!
We may want to start a thread for US Realm Claim Billing nuances! Remember, in the US we can come up with an exception for for every rule, so ...
What you are seeing is the differences between inpatient, outpatient and professional/DMEPOS billing. In general, for an acute inpatient stay there MUST be an admission date and once discharged a discharage date - but we know that hospitals generally bill monthly and people remain in the hospital over a monthend. SO, we there are 'statement dates' - the dates this claim is being submitted for. Once the person is discharged a 'complete' claim will be submitted with all the charges for the entire stay, with an admission, discharge date and statement dates. An inpatient claim MUST have an admission date.
If you are an outpatient, you are technically not 'admitted' to the hospital (NO discussion of Observation stays here), so admission date not required - BUT it could be there IF you are in having services done that will be billed on the inpatient claim once you are admitted (go in a few days early to give blood, have MRI/CT Scan that is inclusive in the inpatient charge...).
For inpatient billing there will always be a revenue code, and there MAY be a CPT/HCPCS code. For professional services there will always be a CPT/HCPCS.
AND every payer may require different information.
Mark Rogers (Dec 03 2020 at 17:41):
Is there any sort of documentation I could peruse on 'how the sausage gets made', as it were, for how each fields were/weren't given MS & how cardinality was assigned? I'm still stumped on questions like "why does the Professional profile not require processNote.text but the other two profiles do require it".
Josh Lamb (Dec 03 2020 at 18:18):
A process note without text would hold no information so this may not have much impact. May be something to keep track of for a future version?
Mark Rogers (Dec 03 2020 at 22:55):
I suppose in this case, I'm worried that a Blue Button app that tells patients why their claims were denied can't show them this information for why Dr Smith's claim was rejected if a payer's system adheres strictly to releasing must-support fields.
Meanwhile, it can tell them why Memorial Hospital's claim was denied. And, it would be because the Inpatient-Institutional profile mandates processNote.text while it's not mandated for Professional.
It looks like the enhancement of adding denial explanations into the IG was approved for inclusion in JIRA (https://jira.hl7.org/browse/FHIR-28244) and I didn't immediately see any notes excluding Professional from scope.
Should we create an additional JIRA to toggle the Professional profile to must-support for processNote.text too?
Pat Taylor (Dec 04 2020 at 17:45):
@Mark Rogers Would you forward your original request to my email at pat.taylor@bcbsa.com? I can't access Zulip from my work computer. It would be helpful to have your screen shots available as I r2search your questions. For example, I'm seeing Professional and Non Clinician .processNote marked as Must Support @MaryKay McDaniel @josh lamb @Amol Vyas
Josh Lamb (Dec 04 2020 at 17:51):
Hi @Pat Taylor , You are correct, ProcessNote is always must support. There are some minor discrepancies with the must support flag on processNote.Text.
Saul Kravitz (Dec 04 2020 at 19:22):
In this particular instance, wouldn't the denial reason on a Professional claim be included in item.adjudication[denialReason]?
Mark Rogers (Dec 09 2020 at 19:16):
@Saul Kravitz Nope, the processNote.text looks like it's something else, at least going off of the JIRA explanation:
*This is a line level payer specific reason conveying a denial explanation to a member, typically goes on the EOB when the payment is denied or disallowed. This is not the same as the CARC / RARC codes payers provide to providers. *
The item.adjudication[denialReason] would be the CARC/RARC, while processNote.text would be...something else? Maybe a human-readable sentence or two? Don't know myself.
Pat Taylor (Dec 21 2020 at 14:18):
@Mark Rogers
Thanks for your analysis. Below are our responses. Some observations require explanations; others will require minor updates to the IG.
careTeam.qualification is only required for Professional and is tagged as MS. There is no MS on Outpatient as it is not required. However, it should reflect the ExampleProviderQualificationCodes from the base Resource, like that for Inpatient. We will update the IG replacing the US Core Provider Specialty (NUCC) Value Set with the Example Value Set on Outpatient.
procedure.type: This is accurate. .procedure is only defined for Inpatient. Values are ICD Procedure Codes. item.productOrService is the FHIR data element for the CPT / HCPCS procedure codes. These codes do not have a procedure type. The FHIR data elements are not required and default to the definition in the base Resource.
procedure[x]: This is accurate. The reason is the same as that given for procedure.type.
item.location: Item.location is only required for Professional and should be tagged as MS. We will update.
item.serviced:
-
Inpatient: Admission and Discharge dates are mapped to a slice supporting.Info.admissionperiod
-
Outpatient: Service date should be a date but not a period. I see it is mapped to a slice. The slicing could be avoided by putting the MS on item.serviced[x] instead of item.serviceDate, since the only option available for serviced[x] is Date. We will update.
-
Professional: Service from and through dates are mapped to item.service.servicePeriod. It should be tagged as MS. We will update.
Cardinality:
Adjudication.denialreason.reason is accurate as denial reasons are provided only at the item level in Professional
.billableperiod is accurate as this situation only applies to Inpatient as an admission may span multiple billing periods if the admission is an extended duration, such as a burn or Covid patient
.insurance for Inpatient should be 1..*. We will update
.item.adjudication for Professional should be 1..*. We will update
.item.adjudication.adjudicationamounttype is accurate. It’s required on Professional but not on Inpatient or Outpatient.
.item.adjudication.denialreason is accurate. It’s required on Professional but not on Inpatient or Outpatient.
.item.revenue for Outpatient should be 1..1. We will update
.procedure.type is accurate as it is only required for Inpatient. See note above.
.supportingInfo: cardinality is accurate. It is based on number of required slices (1..*)
IP: 1..*. -- admissionPeriod is 1..1
OP: 0..*. none are 1..1
Prof: 0..*. none are 1..1
Pharm: 3..*. dayssupply, dawcode and refillnum are 1..1. (1 + 1 + 1 => 3)
.supportingInfo.pointoforigin.code cardinality for Inpatient should be 0..1. We will update.
MustSupport
adjudication:adjudicationamounttype.amount for Inpatient appears to be MS in the IG
billablePeriod start and end MS is accurate; it applies only to Inpatient
careTeam.qualification is accurate; it applies only to Professional
.created for Professional should be MS. We will update
.diagnosis for Outpatient should be MS. We will update
.item.adjudication[allowedunits]value for Professional should be MS. We will update
.item.modifier for Professional should be MS. We will update
.item.productOrService for Professional should be MS. We will update
.item.quantity for Professional should be MS. We will update
.payment.date for Professional should be MS. We will update
.procedure, procedure.date and .procedure.type and procedure[x] are accurate. Procedure only applies to Inpatient. They are ICD procedure codes. The CPT / HCPCS procedure codes are reported in item.productOrService
processNote.text for Professional should be MS. We will update.
@MaryKay McDaniel @Paul Knapp @Saul Kravitz @Amol Vyas @Josh Lamb @Jason Teeple
Last updated: Apr 12 2022 at 19:14 UTC