Da Vinci Payer Data Exchange
2.1.0 - STU2 United States of America flag

Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions

FHIR Artifacts

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

PDEX Server CapabilityStatement

This Section describes the expected capabilities of the PDex Server actor which is responsible for providing responses to the queries submitted by the PDex Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by PDex Servers are defined. PDex Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Behavior: Operation Definitions

These are custom operations that can be supported by and/or invoked by systems conforming to this implementation guide.

PDex Bulk Member Match Operation

The $bulk-member-match operation that can be invoked by either a payer or an EHR or other system, allows one health plan to retrieve a unique identifier for a group resource containing matched members from another health plan using a member’s demographic, coverage information with an accompanying consent record. This identifier can then be used to perform subsequent queries and operations. Health Plans implementing a deterministic match will require a match on member id or subscriber id at a minimum (i.e. A pure demographic match will not be supported by such implementations.).

Behavior: Search Parameters

These define the properties by which a RESTful server can be searched. They can also be used for sorting and including related resources.

ExplanationOfBenefit_Identifier

The business/claim identifier of the Explanation of Benefit

ExplanationOfBenefit_Patient

The reference to the patient

ExplanationOfBenefit_ServiceDate

Date of the service for the EOB. The service-date search parameter simplifies the search, since a client doesn’t need to know that. For inpatient and outpatient institutional EOB dates they need to search by billablePeriod.period.start, for a pharmacy EOB by item.servicedDate, and for a professional and non-clinician EOB - by item.servicedPeriod.period.start.

ExplanationOfBenefit_Type

The type of the ExplanationOfBenefit

ExplanationOfBenefit_Use

The use of the ExplanationOfBenefit

PdexMedicationDispensePatient

Returns dispensed prescriptions for a specific patient. NOTE: This Pdex SearchParameter definition extends the usage context of capabilitystatement-expectation extension to formally express implementer conformance expectations for these elements:

  • multipleAnd
  • multipleOr
  • comparator
  • modifier
  • chain.
PdexMedicationDispenseStatus

Status of the prescription dispense. NOTE: This SearchParameter definition extends the usage context of capabilitystatement-expectation extension to formally express implementer conformance expectations for these elements:

  • multipleAnd
  • multipleOr
  • comparator
  • modifier
  • chain.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

PDex $multi-member-match request

A Parameters profile defining the inputs to a $bulk-member-match operation performed by a payer system

PDex $multi-member-match response

A Parameters profile defining the result of a $bulk-member-match operation performed by a payer system

PDex Consent Profile

The PDex Consent Profile defines the constraints for representing a member’s consent to the sharing of their healthcare information to other organizations.

PDex Device

The PDex Device profile is provided to enable payers to record information about devices used by a member that may not have a UDI number. FHIR-29796 PDex Device uses base resource not US Core Implantable Device Profile. Pdex-Device enables payers to record non-implantable device data. CGP Voted on variance approval: Drew Torres/Eric Haas: 9-0-0

PDex MedicationDispense

Prescription Medications dispensed by a pharmacy to a health plan member and paid for in full, or in part, by the health plan

PDex Member Match Group

A Group List created by the Payer to enable Bulk Payer-to-Payer API access by Other Payers to retrieve member information. Based on the Group resource. An Extension is added to capture the submitted parameters for the access request.

PDex Member No Match Group

A Group List created by the Payer to provide information back to a requesting payer about failed matches. Based on the Group resource. An Extension is added to capture the submitted patient demographics for the access request. The match may have failed for one of two reasons. a) No match on member. b) Matched but unable to comply with consent request.

PDex Prior Authorization

The PDex Prior Authorization (PPA) profile is based on the ExplanationOfBenefit resource and is provided to enable payers to express Prior Authorization information to members

PDex Provenance

Provenance is provided by the payer to identify the source of the information, whether the data came via a clinical record or a claim record and whether the data was subject to manual transcription or other interpretive transformation. This profile adds PayerSourceFormat as an extension on the entity base element.

PDex Provider Group

The Provider Attribution Group List. Based on the Da Vinci Attribution Group (ATRGroup) Profile with the addition of extensions to track latest download for a member. Each member element in the Group record, that is processed by the export operation, should be updated with the execution date/time in lastTransmitted, list of resources (resourceTypes) in lastResources and query filters (filterQueries) in lastFilters.

mTLS Endpoint

The mTLS Endpoint is used to assist payers in defining their mTLS endpoints and discovering other Payer’s mTLS endpoints

mTLS Endpoint Bundle

A bundle of Endpoint and Organization resources to enable mTLS endpoint discovery and configuration.

mTLS Organization

The mTLS Organization record is used to identify the contact information for a Payer that owns a mTLS Endpoint, or is the managing organization tht administers the Endpoint.

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

An attribute to describe the data source a resource was constructed from

Attributes that identify the source record format from which data in the referenced resources was derived

An attribute to express the amount of a service or item that has been utilized

Attribute that expresses the amount of an item or service that has been consumed under the current prior authorization.

An attribute to express the refill number of a prescription

Attribute that identifies the refill number of a prescription. e.g., 0, 1, 2, etc.

LevelOfServiceCode

A code specifying the level of service being requested (UM06)

Member Last Resource Filters

Indicates the filters applied to the resources exported in the last export operation. This string can be taken from the DaVinci Data Export Request _typeFilter Parameter.

Member Last Resource Types

Indicates the resources exported in the last export operation. This string can be taken from the DaVinci Data Export Request _type Parameter.

Member Last Transmission

Indicates the last date/time that data ware requested and transmitted for a member as part of a data delta access request.

Member-Match Input Patient Parameter

Input Patient Parameter supplied for the indiviual member match (Patient Demographics.

Members Opted-out

Indicates the number of members that have opted out of sharing

NDH Associated Servers

Associated Servers

NDH Contactpoint Availabletime

An extension representing the days and times a contact point is available

NDH Dynamic Registration

Dynamic Registration

NDH Endpoint Access Control Mechanism

Endpoint Access Control Mechanism

NDH Endpoint Connection Type Version

An extension for endpoint connection type version

NDH Endpoint Rank

Order established by a Role, Organization… for Endpoints capable of transferring the same content

NDH Endpoint Usecase

EndpointUseCase is an enumeration of the specific use cases (service descriptions) supported by the endpoint

NDH FHIR IG

FHIR IG

NDH Identifier Status

Describes the status of an identifier

NDH Secure Exchange Artifacts

Secure Exchange Artifacts

NDH Trust Framework

Trust Framework

NDH Verification Status

Indicates a resource instance verification status

ReviewAction

The details of the review action that is necessary for the authorization.

ReviewActionCode

The code describing the result of the review.

mTLS Signed Object

mTLS Endpoint Signed Object Extension

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Associated Servers Type Value Set

Associated Servers Type

Endpoint Access Control Mechanism Value Set

Codes for documenting access control mechanism

Endpoint Connection Type Version Value Set

Endpoint Connection Type Version

Endpoint Connection Types Value Set

Endpoint Connection Types

Endpoint FHIR Mimetype Value Set

Endpoint FHIR mimetype

Endpoint Payload Type Value Set

Endpoint Payload Types are constrained to NA (Not Applicable) as part of this IG

FDA National Drug Code (NDC)

The Drug Listing Act of 1972 requires registered drug establishments to provide the Food and Drug Administration (FDA) with a current list of all drugs manufactured, prepared, propagated, compounded, or processed by it for commercial distribution. (See Section 510 of the Federal Food, Drug, and Cosmetic Act (Act) (21 U.S.C. § 360)). Drug products are identified and reported using a unique, three-segment number, called the National Drug Code (NDC), which serves as a universal product identifier for drugs. FDA publishes the listed NDC numbers and the information submitted as part of the listing information in the NDC Directory which is updated daily.

The information submitted as part of the listing process, the NDC number, and the NDC Directory are used in the implementation and enforcement of the Act.

Users should note:

Starting June 1, 2011, only drugs for which electronic listings (SPL) have been submitted to the FDA are included in the NDC Directory. Drugs for which listing information was last submitted to FDA on paper forms, prior to June 2009, are included on a separate file and will not be updated after June 2012.

Information regarding the FDA published NDC Directory can be found here

Users should note a few important items

  • The NDC Directory is updated daily.
  • The new NDC Directory contains ONLY information on final marketed drugs submitted to the FDA in SPL electronic listing files by labelers.
  • The NDC Directory does not contain all listed drugs. The new version includes the final marketed drugs which listing information were submitted electronically. It does not include animal drugs, blood products, or human drugs that are not in final marketed form, such as Active Pharmaceutical Ingredients(APIs), drugs for further processing, drugs manufactured exclusively for a private label distributor, or drugs that are marketed solely as part of a kit or combination product or inner layer of a multi-level packaged product not marketed individually. For more information about how certain kits or multi-level packaged drugs are addressed in the new NDC Directory, see the NDC Directory Package File definitions document. For the FDA Online Label Repository page and additional resources go to: FDA Online Label Repository
Identifier Status Value Set

Codes for Identifier Status

NDH FHIR Endpoint Usecase Value Set

Codes for documenting business use case by a general grouping by business area.

NDH Verification Status Value Set

Codes for verification status

Organization Type VS

Categories of organizations based on criteria in provider directories.

PDex Adjudication

Describes the various amount fields used when payers receive and adjudicate a claim. It includes the values defined in http://terminology.hl7.org/CodeSystem/adjudication, as well as those defined in the PDex Adjudication CodeSystem.

PDex Adjudication Category Discriminator

Used as the discriminator for adjudication.category and item.adjudication.category for the PDex Prior Authorization.

PDex Multi-Member Match Result Value Set

Codes to describe the results group from a multi-member Match operation

PDex Payer Benefit Payment Status

Indicates the in network or out of network payment status of the claim.

PDex SupportingInfo Type

Used as the discriminator for the types of supporting information for the PDEX Prior Authorization. Based on the CARIN IG for Blue Button� Implementation Guide.

Payer source of data

Source Data formats used as the source for FHIR referenced record by the Payer.

Prior Authorization Procedure Codes - AMA CPT - CMS HCPCS - CMS HIPPS

The Value Set is a combination of three Code Systems: CPT (HCPCS I), HCPCS II procedure codes, and HIPPS rate codes. They are submitted by providers to payers to convey the specific procedure performed. Procedure Codes leverage US Core Procedure Codes composition.

The target set for this value set are the procedure codes from the CPT and HCPCS files and the rate codes from the HIPPS files.

The Current Procedural Terminology (CPT) code set, created and maintained by the American Medical Association, is the language of medicine today and the code to its future. This system of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT coding is also used for administrative management purposes such as claims processing and developing guidelines for medical care review. Each year, via a rigorous, evidence-based and transparent process, the independent CPT Editorial Panel revises, creates or deletes hundreds of codes in order to reflect current medical practice.

Designated by the U.S. Department of Health and Human Services under the Health Insurance Portability and Accountability Act (HIPAA) as a national coding set for physician and other health care professional services and procedures, CPT’s evidence-based codes accurately encompass the full range of health care services.

All CPT codes are five-digits and can be either numeric or alphanumeric, depending on the category. CPT code descriptors are clinically focused and utilize common standards so that a diverse set of users can have common understanding across the clinical health care paradigm.

There are various types of CPT codes:

Category I: These codes have descriptors that correspond to a procedure or service. Codes range from 00100–99499 and are generally ordered into sub-categories based on procedure/service type and anatomy.

Category II: These alphanumeric tracking codes are supplemental codes used for performance measurement. Using them is optional and not required for correct coding.

Category III: These are temporary alphanumeric codes for new and developing technology, procedures and services. They were created for data collection, assessment and in some instances, payment of new services and procedures that currently don’t meet the criteria for a Category I code.

Proprietary Laboratory Analyses (PLA) codes: Recently added to the CPT code set, these codes describe proprietary clinical laboratory analyses and can be either provided by a single (solesource) laboratory or licensed or marketed to multiple providing laboratories that are cleared or approved by the Food and Drug Administration (FDA)). This category includes but is not limited to Advanced Diagnostic Laboratory Tests (ADLTs) and Clinical Diagnostic Laboratory Tests (CDLTs), as defined under the Protecting Access to Medicare Act of 2014 (PAMA).

To obtain CPT, please see the license request form here

The Level II HCPCS codes, which are established by CMS’s Alpha-Numeric Editorial Panel, primarily represent items and supplies and non-physician services not covered by the American Medical Association’s Current Procedural Terminology-4 (CPT-4) codes; Medicare, Medicaid, and private health insurers use HCPCS procedure and modifier codes for claims processing. Level II alphanumeric procedure and modifier codes comprise the A to V range.

General information can be found here: https://www.cms.gov/Medicare/Coding/MedHCPCSGenInfo

Releases can be found here: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets

These files contain the Level II alphanumeric HCPCS procedure and modifier codes, their long and short descriptions, and applicable Medicare administrative, coverage and pricing data.

The Health Insurance Prospective Payment System (HIPPS) rate codes represent specific sets of patient characteristics (or case-mix groups) health insurers use to make payment determinations under several prospective payment systems. Case-mix groups are developed based on research into utilization patterns among various provider types. For the payment systems that use HIPPS codes, clinical assessment data is the basic input. A standard patient assessment instrument is interpreted by case-mix grouping software algorithms, which assign the case mix group. For payment purposes, at least one HIPPS code is defined to represent each case-mix group. These HIPPS codes are reported on claims to insurers. Institutional providers use HIPPS codes on claims in association with special revenue codes. One revenue code is defined for each prospective payment system that requires HIPPS codes. HIPPS codes are placed in data element SV202 on the electronic 837 institutional claims transaction, using an HP qualifier, or in Form Locator (FL) 44 ("HCPCS/rate") on a paper UB-04 claims form. The associated revenue code is placed in data element SV201 or in FL 42. In certain circumstances, multiple HIPPS codes may appear on separate lines of a single claim.

HIPPS codes are alpha-numeric codes of five digits. Each code contains intelligence, with certain positions of the code indicating the case mix group itself, and other positions providing additional information. The additional information varies among HIPPS codes pertaining to different payment systems, but often provides information about the clinical assessment used to arrive at the code. Which positions of the code carry the case mix group information may also vary by payment systems.

Prior Authorization Service Type Codes (X12)

Indicates the Type of Service that a Prior Authorization is covering

Prior Authorization value categories

Codes to define Prior Authorization requested, agreed and utilized amounts.

Procedure Codes - AMA CPT - CMS HCPCS - CMS HIPPS

The Value Set is a combination of three Code Systems: CPT (HCPCS I), HCPCS II procedure codes, and HIPPS rate codes. They are submitted by providers to payers to convey the specific procedure performed. Procedure Codes leverage US Core Procedure Codes composition.

The target set for this value set are the procedure codes from the CPT and HCPCS files and the rate codes from the HIPPS files.

The Current Procedural Terminology (CPT) code set, created and maintained by the American Medical Association, is the language of medicine today and the code to its future. This system of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT coding is also used for administrative management purposes such as claims processing and developing guidelines for medical care review. Each year, via a rigorous, evidence-based and transparent process, the independent CPT Editorial Panel revises, creates or deletes hundreds of codes in order to reflect current medical practice.

Designated by the U.S. Department of Health and Human Services under the Health Insurance Portability and Accountability Act (HIPAA) as a national coding set for physician and other health care professional services and procedures, CPT’s evidence-based codes accurately encompass the full range of health care services.

All CPT codes are five-digits and can be either numeric or alphanumeric, depending on the category. CPT code descriptors are clinically focused and utilize common standards so that a diverse set of users can have common understanding across the clinical health care paradigm.

There are various types of CPT codes:

Category I: These codes have descriptors that correspond to a procedure or service. Codes range from 00100–99499 and are generally ordered into sub-categories based on procedure/service type and anatomy.

Category II: These alphanumeric tracking codes are supplemental codes used for performance measurement. Using them is optional and not required for correct coding.

Category III: These are temporary alphanumeric codes for new and developing technology, procedures and services. They were created for data collection, assessment and in some instances, payment of new services and procedures that currently don’t meet the criteria for a Category I code.

Proprietary Laboratory Analyses (PLA) codes: Recently added to the CPT code set, these codes describe proprietary clinical laboratory analyses and can be either provided by a single (solesource) laboratory or licensed or marketed to multiple providing laboratories that are cleared or approved by the Food and Drug Administration (FDA)). This category includes but is not limited to Advanced Diagnostic Laboratory Tests (ADLTs) and Clinical Diagnostic Laboratory Tests (CDLTs), as defined under the Protecting Access to Medicare Act of 2014 (PAMA).

To obtain CPT, please see the license request form here

The Level II HCPCS codes, which are established by CMS’s Alpha-Numeric Editorial Panel, primarily represent items and supplies and non-physician services not covered by the American Medical Association’s Current Procedural Terminology-4 (CPT-4) codes; Medicare, Medicaid, and private health insurers use HCPCS procedure and modifier codes for claims processing. Level II alphanumeric procedure and modifier codes comprise the A to V range.

General information can be found here: https://www.cms.gov/Medicare/Coding/MedHCPCSGenInfo

Releases can be found here: https://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets

These files contain the Level II alphanumeric HCPCS procedure and modifier codes, their long and short descriptions, and applicable Medicare administrative, coverage and pricing data.

The Health Insurance Prospective Payment System (HIPPS) rate codes represent specific sets of patient characteristics (or case-mix groups) health insurers use to make payment determinations under several prospective payment systems. Case-mix groups are developed based on research into utilization patterns among various provider types. For the payment systems that use HIPPS codes, clinical assessment data is the basic input. A standard patient assessment instrument is interpreted by case-mix grouping software algorithms, which assign the case mix group. For payment purposes, at least one HIPPS code is defined to represent each case-mix group. These HIPPS codes are reported on claims to insurers. Institutional providers use HIPPS codes on claims in association with special revenue codes. One revenue code is defined for each prospective payment system that requires HIPPS codes. HIPPS codes are placed in data element SV202 on the electronic 837 institutional claims transaction, using an HP qualifier, or in Form Locator (FL) 44 ("HCPCS/rate") on a paper UB-04 claims form. The associated revenue code is placed in data element SV201 or in FL 42. In certain circumstances, multiple HIPPS codes may appear on separate lines of a single claim.

HIPPS codes are alpha-numeric codes of five digits. Each code contains intelligence, with certain positions of the code indicating the case mix group itself, and other positions providing additional information. The additional information varies among HIPPS codes pertaining to different payment systems, but often provides information about the clinical assessment used to arrive at the code. Which positions of the code carry the case mix group information may also vary by payment systems.

Provenance Agent Type

Agent role performed relating to referenced resource

Secure Exchange Artifacts Value Set

Secure Exchange Artifacts

Trust Framework Type Value Set

Trust Framework Type

Trust Profile Value Set

Codes for documenting trust profile

X12 278 Review Decision Reason Codes

Codes used to identify the reason for the health care service review outcome.

X12 Claim Adjustment Reason Codes - Remittance Advice Remark Codes

X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries.

The X12 Claim Adjustment Reason Codes describe why a claim or service line was paid differently than it was billed. These codes are listed within an X12 implementation guide (TR3) and maintained by X12.

Remittance Advice Remark Codes (RARCs) are used to provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code (CARC) or to convey information about remittance processing.

Each RARC identifies a specific message as shown in the Remittance Advice Remark Code List. There are two types of RARCs, supplemental and informational. The majority of the RARCs are supplemental; these are generally referred to as RARCs without further distinction. Supplemental RARCs provide additional explanation for an adjustment already described by a CARC. The second type of RARC is informational; these RARCs are all prefaced with Alert: and are often referred to as Alerts. Alerts are used to convey information about remittance processing and are never related to a specific adjustment or CARC.

External code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer can be found here:

https://x12.org/codes

Click on the name of any external code list to access more information about the code list, view the codes, or submit a maintenance request. These external code lists were previously published on either www.wpc-edi.com/reference or www.x12.org/codes.

mTLS Bundle Type Value Set

Categories of bundle.

mTLS Signed Object Types

The Object type

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

Credential Status Code System

This code system contains codes for indicating the status of a credential, such as an identifier or qualification.

Endpoint Access Control Mechanism Code System

Endpoint Access Control Mechanism

Endpoint Connection Type Version Code System

Endpoint Connection Type Version

Endpoint Connection Types (additional) Code System

Extension codes for http://terminology.hl7.org/CodeSystem/endpoint-connection-type

Endpoint FHIR MimeType Code System

Endpoint FHIR MimeType

Endpoint HIE Specific Connection Type Code System

Endpoint HIE Specific Connection Type

Endpoint Payload Types Code System

Endpoint Payload Types are constrained to NA (Not Applicable) as part of this IG

Identifier Type

Identifier Type

NDH Associated Servers Type Code System

NDH Associated Servers Type

NDH FHIR Endpoint Use Case Code System

NDH FHIR Endpoint Use Case

NDH Resource Instance Verification Status Code System

NDH Resource Instance Verification Status

NDH Secure Exchange Artifacts Code System

NDH Secure Exchange Artifacts

Organization Type

Categories of organizations based on criteria in provider directories.

PDex Adjudication Codes

Describes the various amount fields used when payers receive and adjudicate a claim. It complements the values defined in http://terminology.hl7.org/CodeSystem/adjudication.

PDex Adjudication Discriminator

Used as the discriminator for the data elements in adjudication and item.adjudication

PDex Identifier Type

Identifier Type codes that extend those defined in http://terminology.hl7.org/CodeSystem/v2-0203 to define the type of identifier payers and providers assign to claims and patients

PDex Multi-Member Match Result Code System

Code set to describe the results group from a multi-member Match operation

PDex Payer Adjudication Status

Describes the various status fields used when payers adjudicate a claim, such as whether the claim was adjudicated in or out of network, if the provider was contracted or non-contracted for the service

PDex Supporting Info Type

Claim Information Category - Used as the discriminator for supportingInfo

Prior Authorization Values

Codes used to define Prior Authorization categories

Provenance Payer Data Source Format

CodeSystem for source formats that identify what non-FHIR source was used to create FHIR record(s)

Provenance Roles

CodeSystem for types of role relating to the creation or communication of referenced resources

Trust FrameworkType Code System

Trust Framework Type

Trust Profile Code System

Trust Profile

mTLS Object Type Code

Codes for the Signed Object Types

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

$multi-member-match payer example request

Example of more than one member being submitted to the PDex Payer-to-Payer Multiple Member Match Operation.

$multi-member-match payer example response

Example of group record being returned in response to PDex Payer-to-Payer Multiple Member Match Operation.

Acme

Payer Organization

BundleConditionWithProvenance

A bundle that returns Conditions with provenance using _revinclude=Provenance:target

BundleExamplePayer1

The bundle pulled from Payer1 by Payer 2 when a member switches to Payer 2. Patient, 2 Encounters and 2 Provenance records.

BundleExamplePayer2

The bundle pulled from Payer2 by Payer 3 when a member switches to Payer 3. Patient, 2 Encounters and 2 Provenance records plus new records from Payer 2.

BundleExamplePayer3

The bundle pulled from Payer3 by Payer 4 when a member switches to Payer 4. Patient, 2 Encounters and 2 Provenance records originating from Payer 1 plus new records from Payer 2 and Payer 3, including supporting Provenance records.

BundleWithProvenance

A bundle that returns provenance using _revinclude=Provenance:target

Example-PDex-Provider-Group

Example of a Payer-generated Member Attribution List for an In-Network/Contracted Provider.

ExampleBundle1

A simple bundle to demonstrate a provenance example

ExampleCoverage

Example of a Coverage for a Member

ExampleDevice

Example of a Device from a Claim

ExampleDocRefProvenance

Example of a PDex Provenance record for a PDF embedded or linked in a DocumentReference resource.

ExampleDocumentReference

Example of a US Core DocumentReference with a linked PDF document. The document could also be embedded.

ExampleEncounter1

Example of an Encounter that has a provenance record received by Payer 1

ExampleEncounter2

Example of an Encounter that has a provenance record received by Payer 1

ExampleEncounter3

Example of an Encounter that has a provenance record received by Payer 2

ExampleLocation

Example of a Pharmacy Location Record

ExampleMedicationDispenseClaim

Example of a MedicationDispense from a Claim

ExamplePractitioner

Example of a Practitioner Record

ExampleProvenanceAuthorEncounter6

Example of an author Provenance record displaying a practitioner’s organization as the author

ExampleProvenanceAuthorEncounter7

Example of an author Provenance record displaying a practitioner’s organization as the author

ExampleProvenanceBundleTransmitter

Example of a Transmitter Provenance record for a bundle

ExampleProvenanceCustodian

Example of a Custodian Provenance record for the contents of a bundle received from another payer

ExampleProvenancePayerModified

Example of provenance based on security group recommendations

ExampleProvenancePayerSource

Example of a payer being the source of the data

ExampleProvenanceSoloPractitioner

Example of an author Provenance record displaying a sole practitioner as the author

ExampleProvenanceTransmitter

Example of a Transmitter Provenance record for a bundle

OrganizationPayer1

Example of the Payer Organization

OrganizationPayer1-1

Example of the Payer Organization

OrganizationPayer2

Another Example of the Payer Organization

OrganizationPayer2-2

Another Example of the Payer Organization

OrganizationProvider1

Provider Organization Example 1

OrganizationProvider2

Provider Organization Example 1

Patient1

Example of a US Core Patient Record for Payer 1

Patient1-2

Example of a US Core Patient Record for Payer 2

Patient100

Example of a US Core Patient Record for Payer 2

Patient1001

Example of a US Core Patient Record matched by old payer in Bulk Member Match

Patient2002

Example of a US Core Patient Record matched by old payer in Bulk Member Match

PdexPriorAuth

PDex Prior Authorization based on EOB Inpatient Example

PriorAuthCoverage

Health Plan Coverage for Prior Authorization

diamond-mtls-endpoint1

NDH Endpoint compliant Profile as an example of Payer mTLS Endpoint that is linked from Organization and incorporated in bundle

diamond-mtls-endpoint2

National Directory Query Endpoint Profile as an example of Payer mTLS Endpoint that is linked from Organization and incorporated in bundle

example-mtls-endpoint-bundle

Example of mTLSbundle for Payer Endpoint for Payer-to-Payer Exchange

example-pdex-member-consent-constraint-group

Example of PDex Member Match Group that returns matches that fail the consent decision flow.

example-pdex-member-match-group

Example of PDex Member Match Group that returns successful matches and creates a Group resource for use with bulk operations.

example-pdex-member-no-match-group

Example of PDex Member Match Group that returns unsuccessful matches.

mtlsorganization2

Example of mTLS Organization