Notes on Fields

• The EOB FHIR Resource defines a comprehensive set of data elements.  Many of them are not relevant to this use case.  When reviewing the Profile Snapshot, several data elements previously hidden are now exposed.  Fields intended for consideration to be provided in the API are marked as Must Support; i.e., a red S or have a minimum cardinality of 1.  All other data elements are not expected to be sent by a Responder; if they are sent a Requestor can choose to ignore them
• CPCDS data elements are mapped to EOB header or EOB.item data elements in alignment with claims submission standards.  Line item amounts, amount types and the in network or out of network payment status of the line are to be provided in EOB.item.  Total amounts and amount types of the claim are to be provided in EOB.total.
• ExplanationOfBenefit.item.productOrService:  values are NDC Codes when Compound Code (MapID 78) = 0 or 1.  When the Compound Code = 2, productOrService = "compound" and map the ingredient to ExplanationOfBenefit.item.detail.productOrService
• ExplanationOfBenefit.item.productOrService and item.detail.productOrService: Payers shall provide an 11-digit NDC. For additional information, reference the Other useful Information in the HL7 Terminology Authority - External Terminologies - NDC Confluence site, https://confluence.hl7.org/pages/viewpage.action?pageId=97453858
• ExplanationOfBenefit.item.quantity:  populate for all Compound Code values.  When the Compound Code = 2, if available, map the ingredient to ExplanationOfBenefit.item.detail.quantity
• ExplanationOfBenefit.item.adjudication.amount:  Eligible amount = ingredient cost + dispensing fee + sales tax + vaccine administration fee.  Excludes manufacturer discounts.  If benefit payment status code = 'Y', discount = submitted – noncovered – eligible; otherwise discount = 0.  The subscriber pays the member liability = deductible + coinsurance + copay + noncovered.  (part of the member liability may have already been paid to the provider as paidbypatient).  The eligible amount - the member liability is the payment amount to the provider (paidtoprovider). 
• ExplanationOfBenefit.total.amount:  Eligible amount = ingredient cost + dispensing fee + sales tax + vaccine administration fee.  Excludes manufacturer discounts.  If benefit payment status code = 'Y', discount = submitted – noncovered – eligible; otherwise discount = 0.  The subscriber pays the member liability = deductible + coinsurance + copay + noncovered.  (part of the member liability may have already been paid to the provider as paidbypatient).  The eligible amount - the member liability is the payment amount to the provider (paidtoprovider). 
• ExplanationOfBenefit.adjudication[benefitpaymentstatus]:  in network or out of network payment status for the claim
• ExplanationOfBenefit.adjudication elements may contain slices for both billing network status (billingnetworkstatus) and benefit payment status (benefitpaymentstatus) which each contain a reason code bound to very similar ValueSets that indicate network status. The billing network status indicates the general relationship (often a contract status) the billing provider has with the payer. The benefit payment status indicates how the service or product is covered (in or out of network) in context to its provisioning. These two values may be different.
  An example of this is where an in network provider that has billed for a service that is not within the scope of the contract of service with the payer.
• The CPCDS data elements are defined in the data element comments.  The numbers, e.g. (1), following the data element descriptions in the comments correlate to the MapID in the CPCDS Data Dictionary and the Mapping Worksheet as described here.
• meta.profile is required as a matter of convenience of receiving systems. The meta.profile should be used by the Server to hint/assert/declare that this instance conforms to one (or more) stated profiles (with business versions). meta.profile does not capture any business logic, processing directives, or semantics (for example, inpatient or outpatient). Clients should not assume that the Server will exhaustively indicate all profiles with all versions that this instance conforms to. Clients can (and should) perform their own validation of conformance to the indicated profile(s) and to any other profiles of interest.