Stream: implementers
Topic: CARIN BB IG
John Timm (Nov 07 2019 at 22:05):
I've been looking through the CARIN BB IG here:
https://build.fhir.org/ig/HL7/carin-bb/index.html
And have been noticing some issues with the way constraints are defined. For example, in this profile:
https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-CARIN-BB-ExplanationOfBenefit-Inpatient-Facility.html
There are a number of slices defined on ExplanationOfBenefit.supportInfo and all of them have a fixed value for category. The problem is that the ElementDefinition for category in these slices is specified as follows:
{
"id" : "ExplanationOfBenefit.supportingInfo:billingnetworkcontractingstatus.category",
"path" : "ExplanationOfBenefit.supportingInfo.category",
"short" : "Classification of the supplied information",
"definition" : "The general class of the information supplied: information; exception; accident, employment; onset, etc.",
"comment" : "This may contain a category for the local bill type codes.",
"requirements" : "Required to group or associate information items with common characteristics. For example: admission information or prior treatments.",
"min" : 1,
"max" : "1",
"base" : {
"path" : "ExplanationOfBenefit.supportingInfo.category",
"min" : 1,
"max" : "1"
},
"type" : [
{
"code" : "CodeableConcept"
}
],
"fixedCoding" : {
"system" : "http://hl7.org/fhir/us/carin/CodeSystem/carin-bb-claiminformationcategory",
"code" : "billingnetworkcontractingstatus"
},
"isModifier" : false,
"isSummary" : false,
"binding" : {
"extension" : [
{
"url" : "http://hl7.org/fhir/StructureDefinition/elementdefinition-bindingName",
"valueString" : "InformationCategory"
}
],
"strength" : "example",
"description" : "The valuset used for additional information category codes.",
"valueSet" : "http://hl7.org/fhir/ValueSet/claim-informationcategory"
}
},
There is a fixed value for a CodeableConcept defined using a fixedCoding. The types don't match. Furthermore, the FHIR spec mentions this here:
http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.fixed_x_
This is not recommended for Coding and CodeableConcept since these often have highly contextual properties such as version or display.
In other implementation guides patternCodeableConcept is used in this scenario. Does anyone know the rationale behind using fixed in this context? I believe it is an error in the IG.
Grahame Grieve (Nov 07 2019 at 22:10):
@Amol Vyas
John Timm (Nov 07 2019 at 22:21):
Interestingly, patternCodeableConcept is used on other profiles in the same IG:
https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-CARIN-BB-ExplanationOfBenefit-Outpatient-Facility.json.html
John Timm (Nov 08 2019 at 14:09):
Updated dated sample ElementDefinition to illustrate a fixedCoding constraint on an element of type CodeableConcept
Amol Vyas (Nov 12 2019 at 10:05):
Thanks @John Timm for the feedback. Per this discussion, we're currently harmonizing the CARIN BB profiles to use pattern, among other best practice updates. These updates will be available in a new build soon.
Yengibar Manasyan (Jun 30 2020 at 20:50):
In Carin BB IG there are multiple profiles like this:
CARINBBExplanationOfBenefit
CARINBBExplanationOfBenefitInpatientFacility
CARINBBExplanationOfBenefitOutpatientFacility
CARINBBExplanationOfBenefitPharmacy
CARINBBExplanationOfBenefitProfessionalNonClinician
In the capability statement, I see a resource ExplanationOfBenefit which has one profile: http://hl7.org/fhir/us/carin/StructureDefinition/carin-bb-explanationofbenefit. I assume this is CARINBBExplanationOfBenefit. And under it, there are 2 search parameters: patient and created.
Does it mean that searches must be done against only CARINBBExplanationOfBenefit profile and not CARINBBExplanationOfBenefitInpatientFacility, ..., and CARINBBExplanationOfBenefitOutpatientFacility?
If [base]/ExplanationOfBenefit/patient=something&created=somethingelse must always return CARINBBExplanationOfBenefit, than where CARINBBExplanationOfBenefitInpatientFacility, ..., and CARINBBExplanationOfBenefitOutpatientFacility must be used?
@Grahame Grieve @Amol Vyas
Michele Mottini (Jun 30 2020 at 21:09):
You search the resource, then the resources that come back from that search can match different profiles
Yengibar Manasyan (Jul 01 2020 at 14:59):
@Michele Mottini do you mean that as a result of search [base]/ExplanationOfBenefit/patient=something&created=somethingelse can be returned resources with CARINBBExplanationOfBenefit, CARINBBExplanationOfBenefitInpatientFacility, CARINBBExplanationOfBenefitOutpatientFacility, etc profiles?
Michele Mottini (Jul 01 2020 at 15:05):
Yes
Yengibar Manasyan (Jul 01 2020 at 15:07):
In that case, maybe we must have supportedProfiles in the capabilityStatement with all of these profiles for ExplanationOfBenefit resource?
Yengibar Manasyan (Jul 01 2020 at 15:24):
@Michele Mottini ?
Michele Mottini (Jul 01 2020 at 15:28):
Don't know - why does it matter? (I think uur server does not list anything in supported profiles )
Yengibar Manasyan (Jul 01 2020 at 15:30):
To make it clear for implementers and later for clients that the returned resources can have the specific profiles
Michele Mottini (Jul 01 2020 at 15:32):
Cannot really see how clients would use that information
Yengibar Manasyan (Jul 01 2020 at 16:28):
@Michele Mottini for searching resources specifically with CARINBBExplanationOfBenefitOutpatientFacility should clients use _profile=CARINBBExplanationOfBenefitOutpatientFacility search parameter? Do you think that it makes sense or overall clients shouldn't care about the profile and do searches just based on patient and/or created search parameters?
Michele Mottini (Jul 01 2020 at 16:31):
No, I do not think that make much sense - search for of ExplanationOfBenefit regardless of the profile. Use the profile (or the actual part of the profile you need) as a guide on how to process the data, but that happens when you write the code, not at runtime
Yengibar Manasyan (Jul 01 2020 at 17:40):
@Michele Mottini do you think that from Carin BB IG prospective clients don't need to search e.g. patient's pharmacy EOBs (search using patient and _profile parameters)?
Michele Mottini (Jul 01 2020 at 17:45):
If you want pharmacy you'd search by type (if that's available), not by profile
Yengibar Manasyan (Jul 01 2020 at 17:53):
In CARIN BB capability statement and search parameters I wasn't able to find type search parameter, should it be there or it's not a useful search scenario for CARIN BB?
Michele Mottini (Jul 01 2020 at 17:56):
I think the search parameters are still in flux ? I do not see them defined in the published IG
Michele Mottini (Jul 01 2020 at 17:57):
In our app we do not care - we get all ExplanationOfBenefit for the patient
Michele Mottini (Jul 01 2020 at 17:59):
CMS BlueButton supports it (see 'Query by Type' in https://bluebutton.cms.gov/developers/ ) - so I guess CARIN BB should as well
Yengibar Manasyan (Jul 01 2020 at 18:06):
thank you, make sense
David Pyke (Jul 01 2020 at 19:01):
It's important to note that the CARIN BB IG is still in heavy development. Things will change
Igor Sirkovich (Jul 02 2020 at 03:32):
@Yengibar Manasyan , the list of the search parameters should be finalized in the next couple of weeks. Most likely, these would include patient, _id, _lastUpdated, identifier, service-date and type. So you would be able to search for all pharmacy EOBs of a patient in a specified between two dates or for all institutional (in and out patient) EOBs of a patient that have changed since some timestamp for example.
Yengibar Manasyan (Sep 16 2020 at 14:38):
@Igor Sirkovich how I can find information about iterate modifier usage in Carin BB IG?
Should we support iterate modifier for _include and/or for _revinclude?
Jason Teeple (Sep 18 2020 at 14:54):
Yengibar Manasyan said:
Igor Sirkovich how I can find information about iterate modifier usage in Carin BB IG?
Should we support iterate modifier for _include and/or for _revinclude?
You can try your luck in the CARIN BB Stream as well. I sent an email to @Ryan Howells asking the same question.
Michele Mottini (Sep 18 2020 at 15:12):
@Yengibar Manasyan see https://chat.fhir.org/#narrow/stream/204607-CARIN-IG.20for.20Blue.20Button.C2.AE/topic/API.20and.20Search.20Params - :iterate was surely mentioned but it is not in the current implementation guide. If you are working on a server I would not worry about it for now (our client for sure does not rely on it, and I bet Apple Health does not as well)
Igor Sirkovich (Sep 18 2020 at 17:53):
@Yengibar Manasyan ":iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor. There is no way to express this in the CapabilityStatment, so this somehow disappeared from the IG. I believe we'll get it back in one of the IG narrative descriptions. We don't have any other use for "_include:iterate" in CARIN BB and we don't have any " _revinclude"s.
Paul Church (Sep 18 2020 at 18:12):
Yep, this is something I brought up this week (include on Coverage:payor has to be an iterate, since you can't search on Coverage) and should be straightened out at some point.
Michele Mottini (Sep 18 2020 at 19:00):
You can GET Coverage
Paul Church (Sep 18 2020 at 19:08):
You can't _include on a read operation though
Michele Mottini (Sep 18 2020 at 19:24):
....then you GET Practitioner etc ... that what clients would do most likely, includes are not much used
Paul Church (Sep 18 2020 at 19:33):
The IG considers it important to be able to do a search on EoB and retrieve all supporting resources through includes in a single call. I guess we'll see what the adoption of this pattern looks like.
Igor Sirkovich (Sep 21 2020 at 14:28):
CARIN BB IG supports both approaches: 1) do a search on EoB and retrieve all supporting resources through includes in a single call; 2) read/vread on individual reference resources. A client app can select the approach. A server shall support both.
René Spronk (Sep 21 2020 at 14:54):
Follow up detailed question: vread? Does CARIN BB IG mandate that servers support vread? (you weren't stating that, I know, I'm just curious).
Igor Sirkovich (Sep 22 2020 at 01:37):
@René Spronk, "read" is SHALL, "vread" is SHOULD - if a payer supports historical data / retrieval of point in time reference data that was valid on the adjudication date, then they are supposed to have versioned references and support "vread".
Pat Taylor (Sep 30 2020 at 21:51):
@Saul Kravitz @Mark Roberts @Amol Vyas @Ryan Howells
Ryan Howells (Oct 01 2020 at 03:23):
Hey @Paul Church: Are there any search parameters you would recommend modifying based on how they are listed in the 0.1.3 version? Do you envision a use case where someone doesn't make a single call for all of the supporting resources related to EoB?
Paul Church (Oct 01 2020 at 03:56):
I don't have any further suggestions for search parameters at the moment. Some connectathon testing would be useful!
Use cases that aren't a single call...it's clear that many participants wanted to stick to the path of a single call as much as possible, which I think will work. Because all of the includes are forward (following references, rather than looking up incoming references), the client could follow them with 'read' or 'vread' requests. So even if the client wants to retrieve results piece by piece I think we don't need to require search on anything else.
Pagination may be a pain point in full-scale deployment. FHIR search counts the page size as the number of primary results (EOBs in this case), and the server then adds every included (supporting) resource linked to those primary results to create a complete bundle. Clients may need to request a relatively small page size because the supporting resources could expand the results a lot.
John Achoukian (Oct 22 2020 at 23:38):
@Paul Church Are modifiers such as :missing a requirement to support? For example: GET [base]/ExplanationOfBenefit?_lastUpdated:missing=true
Paul Church (Oct 22 2020 at 23:55):
It's not called out in the current IG materials, as far as I'm aware. There's a lot of potential depth in search that IGs don't always dig into. In general the need for certain modifiers would be established through real-world experience at the trial use stage and added to later versions of the IG.
John Achoukian (Oct 23 2020 at 00:05):
Thanks @Paul Church
Ruth berge (Jan 15 2021 at 05:16):
the Carin pharmacy profile (http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy) contains supportingInfo:refillNum and that links to a code system http://hl7.org/fhir/ValueSet/claim-exception which has two entries, one for student and one for disabled. How do these codes relate to a refill number? Or, are we supposed to add to the value set? Or is there another option?
Ruth berge (Jan 15 2021 at 05:21):
the Carin pharmacy profile (http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy) contains supportingInfo:refillNum and that links to a code. Separately I asked about the code system. Here I just want to ask why there is a code system for refill number at all? In Medication Request the same information is an unsigned int (MedicationRequest.dispenseRequest.numberOfRepeatsAllowed)
Lloyd McKenzie (Jan 15 2021 at 05:47):
You might want to ask here: #CARIN IG for Blue Button®
Ruth berge (Jan 15 2021 at 21:06):
@Lloyd McKenzie I have moved this to Carin BB group (which I tried to find first...) Thanks.
Chetana Nayyar (Feb 03 2021 at 15:10):
Regarding the Prior Authorization is there any FHIR resource or profile to handle an ongoing prior-authorization?
I do see in the EOB that there is a column EOB.insurance.preAuthRef but which is more like a reference numbers previously provided by the insurer to the provider to be quoted on subsequent claims containing services or products related to the prior authorization.
Lloyd McKenzie (Feb 03 2021 at 17:33):
ClaimResponse is used to represent prior authorizations (and pre-determinations)
Jason Buys (Apr 12 2021 at 16:42):
(deleted)
Jason Buys (Apr 12 2021 at 16:43):
how do I delete?
Eric Haas (Apr 12 2021 at 17:45):
(deleted)
guninder (Feb 04 2022 at 07:06):
Hello !
We are implementing CARIN's profiles for and are creating c4bb EOB resources based on this-
http://hl7.org/fhir/us/carin-bb/STU1/StructureDefinition-C4BB-ExplanationOfBenefit-Pharmacy.html
Basically, we are through with it but the only thing we are failing for the is the value-set mentioned in the profile for ExplanationOfBenefit.supportingInfo:dawcode.code which is
Link - http://hl7.org/fhir/us/carin-bb/STU1/ValueSet-NCPDPDispensedAsWrittenOrProductSelectionCode.html
As per this URL (https://build.fhir.org/ig/HL7/carin-bb/ValueSet-NCPDPDispensedAsWrittenOrProductSelectionCode.html) FHIR doesn’t give detail on the value-set required and we don’t have licensed NCPDP codes to support this.
Although we had tried passing the DAW standard code values 0-9 from this https://ushik.ahrq.gov/ViewItemDetails?system=mdr&itemKey=60578000
But still not getting through.
So, seeking help /advice on how to get through it. Any alternative value-set and code can be used here. Any help or pointers on this is appreciated.
Thank you!
René Spronk (Feb 04 2022 at 07:33):
The above is a duplicate question.. please give the readers some time to respond (a couple of days) before reposting. #CARIN IG for Blue Button® would be the best stream for this type of question anyway, not this generic #implementers stream.
guninder (Feb 04 2022 at 07:41):
René Spronk said:
The above is a duplicate question.. please give the readers some time to respond (a couple of days) before reposting. #CARIN IG for Blue Button® would be the best stream for this type of question anyway, not this generic #implementers stream.
Ok , sure ...So do you suggest to repost in #CARIN IG for Blue Button® ?
René Spronk (Feb 04 2022 at 09:20):
Given the topic, yes, given that its far more likely to be answered by the participants of that stream. Good luck!
Last updated: Apr 12 2022 at 19:14 UTC
