FHIR Chat · Usage of Claim.item · Da Vinci PAS

Stream: Da Vinci PAS

Topic: Usage of Claim.item


view this post on Zulip Tushar Nair (Jan 28 2022 at 18:01):

Hello,
The PAS Claim spec has set the cardinality of the 'Claim.item as (1..*). However my understanding is, in the X12 278 request the Loop 2000F is used in a situational manner and is not 'required' as such. if that is the case then how are we going to handle this in scenarios where the service line is not used in the X12 278 request transaction?

view this post on Zulip Jean Duteau (Jan 28 2022 at 18:14):

a FHIR PAS request will always have one item because the details of the overall claim will go in that item. The FHIR Claim resource doesn't allow for the detail that is needed to convey what is being asked to be sent in anything but the item.

view this post on Zulip Jean Duteau (Jan 28 2022 at 18:15):

the details of that can be found in the X12 mapping document

view this post on Zulip Tushar Nair (Jan 28 2022 at 18:29):

@Jean Duteau thank you for the prompt response. I went through the mapping doc and I noticed this sentence in it- "Each occurrence of Claim.item[ n] will have a corresponding 2000F occurrence " but that's where it is confusing. It seems, it is sort of mandating the use of 2000F loop. How can we do that when the 278 spec makes it optional/situational? Pardon me, if this has been discussed and addressed, but I coudn't find any reference in the threads above.
Also on a side-note, I am assuming the mapping provided can be used either way: Source(FHIR)-Target(278) OR Source (278)- Target (FHIR)

view this post on Zulip Tushar Nair (Jan 31 2022 at 18:59):

based on the feedback above, I am assuming that Claim.item SHALL BE ALWAYS populated. In that case, is it implicit that certain fields have to be populated one way or the other. e.g. if the 278 request has a medication code (J Codes) in the service line 2000F, then it means the same code shall be populated in the 'Claim.item.extension-requestedService.MedicationRequest.medication.medicationCodeableconcept.coding.code'? the reason I am asking this is because in the X12 mapping document this mapping has not been mentioned. Similarly we may have to cover for other fields likeve servicerequest.code, DeviceRequest.code etc. Basically, it's an implementation decision to fill out the mapping as per their own requirements where we see certain gaps? @Jean Duteau

view this post on Zulip Jean Duteau (Jan 31 2022 at 19:21):

@Paul Knapp @MaryKay McDaniel any help for Tushar?

view this post on Zulip MaryKay McDaniel (Feb 04 2022 at 00:03):

@Tushar Nair Tushar, I believe the document you are referring to is produced and owned by X12. I would suggest you address your comments on updates to the mapping to them. That way we can get the right folks involved. Suggest you start by sending an email to support@x12.org. Thanks!!!


Last updated: Apr 12 2022 at 19:14 UTC