This page is part of the Da Vinci Payer Data Exchange (v2.0.0: STU2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
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. |
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:
|
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:
|
These define constraints on FHIR resources for systems conforming to this implementation guide.
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 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. |
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. |
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) |
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 |
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
|
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 Payer Benefit Payment Status |
Indicates the in network or out of network payment status of the claim. |
PDex Provider Export Value Set |
Provider Request Export Mode |
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: 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 |
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 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 Provider Export Mode |
Data Export Mode Types for Provider Export Operation. |
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 |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
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 |
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 |
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 |
mtlsorganization2 |
Example of mTLS Organization |