Da Vinci Clinical Data Exchange (CDex)
2.0.0-ballot - Ballot US

This page is part of the Da Vinci Clinical Documentation Exchange (v2.0.0-ballot: STU2 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.1.0. For a full list of available versions, see the Directory of published versions

CodeSystem: CDex Temporary Code System

Official URL: http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp Version: 2.0.0-ballot
Draft as of 2021-10-26 Computable Name: CDexTempCodes

Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License

Codes temporarily defined as part of the CDex implementation guide. These will eventually migrate into an officially maintained terminology (likely HL7’s UTG code systems).

The following page is DRAFT and open for review

This Code system is referenced in the content logical definition of the following value sets:

This code system http://hl7.org/fhir/us/davinci-cdex/CodeSystem/cdex-temp defines the following codes:

CodeDisplayDefinition
claims-processing Claim ProcessingRequest for data necessary from payers to support claims for services.
preauth-processing Pre-authorization ProcessingRequest for data necessary from payers to support pre-authorization for services.
risk-adjustment Risk AdjustmentRequest for data from payers to calculate differences in beneficiary-level risk factors that can affect quality outcomes or medical costs, regardless of the care provided.
quality-metrics Quality MetricsRequest for data used for aggregation, calculation and analysis, and ultimately reporting of quality measures.
referral ReferralRequest for additional clinical information from referring provider to support performing the requested service.
social-care Social CareRequest for data from payers to support the non-medical social needs of individuals, especially the elderly, vulnerable or with special needs.
authorization-other Other AuthorizationRequest for data from payers for other authorization request not otherwise specified.
care-coordination Care CoordinationRequest for data from payers to create a complete clinical record for each of their members to improve care coordination and provide optimum medical care.
documentation-general General DocumentationRequest for data used from payers or providers for general documentation.
orders OrdersRequest for additional clinical information from referring provider to support orders.
patient-status Patient StatusRequests for patient health record information from payers to support their payer member records.
signature SignatureRequest for signatures from payers or providers on requested data.
care-planning Care PlanningRequest for data from payers or providers to determine how to deliver care for a particular patient, group or community.
social-risk Social RiskRequest for data from payers or other providers to assess of social risk, establishing coded health concerns/problems, creating patient driven goals, managing interventions, and measuring outcomes.
operations-nos Operations Not Otherwise Specified[Healthcare Operations as defined by HIPAA](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html) and isn't defined further to ascertain a more detailed Purpose of Use concept.
payment-nos Payment Not Otherwise Specified[Healthcare Payment as defined by HIPAA](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/index.html) and isn't defined further to ascertain a more detailed Purpose of Use concept.
purpose-of-use Purpose Of UsePurpose of use for the requested data.
signature-flag Signature FlagFlag to indicate whether the requested data requires a signature.
tracking-id Tracking IdA business identifier that ties requested attachments back to the claim or prior-authorization (referred to as the “re-association tracking control numbers”).
multiple-submits-flag Multiple Submits FlagFlag to indicate whether the requested data can be submitted in multiple transactions. If true the data can be submitted in separate transactions. if false *all* the data should be submitted in a single transaction.
payer-url Payer URL$submit-attachment operation endpoint where the requested data can be submitted
service-date Service DateDate of service or starting date of the service for the claim or prior authorization.
attachment-request Attachment RequestA Task by a Payer requesting attachments for a claim or prior-authorization from the Provider. The Provider is expected to submit the attachments using the $submit-attachment operation to the endpoint provided in the "payer-url" input parameter.