In response to your 1st question,
FHIR is a base standard for the definition and exchange of healthcare related information. It is focused around “resources” which are a collection of specific elements that define a specific concept (e.g. Practitioner, Observation).
US Core is a set of “profiles” that constrain the resources for a specific use case. They may constrain the cardinality of a specific element (e.g. require the element to be present), define a specific value set to be used for particular element (e.g. RxNorm for a medication) and bind extension (additional elements not found in the base) to the specific resource.
Da Vinci Payer Data Exchange (PDex) is an implementation guide that defines one or more specific use cases (e.g. the exchange of payer clinical data to a provider, member, or other payer). It establishes the content of the exchange (profiles, value sets, extension, …) and the operations (RESTful exchanges, messaging, …) security requirements (e.g. SMART OAuth 2.0) and conformance statements used for the exchanges defined by the implementation guide.
CARIN BB (now called Consumer Directed Payer Data Exchange or CDPDE) is a FHIR implementation guide addressing the use case of exchanging claims based data from a payer to the member’s application based on the FHIR ExplanationOfBenefit resource.
Think of CDPDE as representing the FHIR version of the EOB you receive from your payer after they adjudicate a claim today.
Think of PDex as all payer data represented as “clinical’ activities (not financial).
Both implementation guides use FHIR as the base standard and, where possible, use US Core profiles to constrain the base.
In response to your 2nd question,
The Da Vinci use cases provide clinical data from payers to EHRs and providers. The CARIN BB use case supports providing payer adjudication data resulting from a claims submission using the EOB Resource. Neither the EOB nor Coverage Resource are part of USCore. Payers are recommending HL7 consider inclusion of the EOB and Coverage resources in a future version of both USCDI and US Core.
In response to your 3rd question,
FHIR requires some data elements that were not called out in the CPCDS. For example, ExplanationOfBenefit.use has a cardinality of 1…1. This would be a data element in the Pharmacy EOB that is not in the mapping. Other contributors may be the ‘slicing’ of supportingInfo to define NCPDP data elements that are not defined in the base resource.