This fragment is available on ImplementationGuide-hl7.fhir.us.davinci-cdex.html
This publication includes IP covered under the following statements.
Type | Reference | Content |
---|---|---|
web | example.org | subject : http://example.org/fhir/Patient/cdex-example-patient |
web | example.org | asserter : http://example.org/fhir/PractitionerRole/126 |
web | example.org | http://example.org/fhir/Practitioner/123 |
web | example.org | Questionnaire: CDEX Questionnaire Example2 |
web | example.org | for : http://example.org/fhir/Patient/cdex-example-patient |
web | example.org | requester : http://example.org/fhir/Organization/cdex-example-payer |
web | example.org | owner : http://example.org/fhir/Organization/cdex-example-provider |
web | example.org | basedOn : http://example.org/fhir/CommunicationRequest/cdex-example-authorization |
web | example.org | basedOn : http://example.org/fhir/CommunicationRequest/cdex-example1-authorization |
web | example.org | http://example.org/fhir/Condition/858 |
web | example.org | value : http://example.org/fhir/Condition/858 |
web | example.org | value : http://example.org/fhir/Provenance/858 |
web | example.org | http://example.org/fhir/Bundle/858p |
web | example.org | value : http://example.org/cdex/payer/$submit-attachment |
web | example.org | http://example.org/fhir/Bundle/cdex-searchbundle-scenario1-example |
web | example.org | about : http://example.org/fhir/Claim/cdex-example-claim |
web | example.org | requester : http://example.org/fhir/Organization/cdex-example-referred-to-provider |
web | example.org | recipient : http://example.org/fhir/Organization/cdex-example-referred-to-provider |
web | example.org | sender : http://example.org/fhir/Organization/cdex-example-referring-provider |
web | github.com | Da Vinci Clinical Data Exchange (CDex), published by HL7 International / Payer/Provider Information Exchange Work Group. 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-ecdx/ and changes regularly. See the Directory of published versions |
web | example.org | subject : http://example.org/cdex/provider/fhir/Patient/06e1f0dd-5fbe-4480-9bb4-6b54ec02d31b |
web | example.org | encounter : http://example.org/cdex/provider/fhir/Encounter/5fe62cd5-bfcf-4d3b-a1e9-80d6f75d6f82 |
web | example.org | http://example.org/cdex/provider/fhir/Practitioner/Dr-Jones-12345 |
web | example.org | http://example.org/cdex/provider/fhir/Organization/good-health-54321 |
web | example.org | subject : Elden718 Halvorson124 |
web | example.org | author : Janeth814 Jakubowski832, MD |
web | example.org | https://example.org/fhir/Subscription/cdex-task-inline-scenario1-subscription-active |
web | cdex.ri.argo.run | https://cdex.ri.argo.run/fhir/provider/Task/cdex-task-example2 |
web | www.iso.org |
ISO Maintains the copyright on the country codes, and controls it's use carefully. For futher details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
Show Usage
|
web | ucum.org |
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
Show Usage
|
web | browser.ihtsdotools.org |
QuestionnaireAnswerCodes
(a valid code from SNOMED CT
) http://hl7.org/fhir/ValueSet/questionnaire-answers
From the FHIR Standard
|
web | en.wikipedia.org | Both Bundle.link and Bundle.entry.link are defined to support providing additional context when Bundles are used (e.g. HATEOAS ). |
web | x12.org | This value set includes LOINC terms that can be sent by a payer as part of an HL7 attachment request for additional documentation. It has been curated by the HL7 Payer/Provider Information Exchange (PIE) Work Group. More information about using LOINC in HIPAA attachments and the source of this value set can be found at https://loinc.org/attachments. For prior authorization, X12 PWK01 Report Type Codes may also be used. |
web | example.org | http://example.org/FHIR/Payer/cdex-task-watch |
web | x12.org | Please see https://x12.org/products/licensing-program |
web | flowchart.js.org | Text based source : These textual representations of the diagrams ( the text between the ''') can be viewed and edited using flowchart.js . flowchart.js is a flowchart DSL and SVG renderer that runs in the browser and terminal. For more information, see https://flowchart.js.org/ . Alternatively, this text can be viewed directly at https://hackmd.io/ . |
web | hackmd.io | Text based source : These textual representations of the diagrams ( the text between the ''') can be viewed and edited using flowchart.js . flowchart.js is a flowchart DSL and SVG renderer that runs in the browser and terminal. For more information, see https://flowchart.js.org/ . Alternatively, this text can be viewed directly at https://hackmd.io/ . |
web | fhir.github.io | A validator that can be used to check FHIR resource instance validity and instructions on how to use it |
web | x12.org | This guide uses the terms "attachments" and "additional information" to mean additional information needed for claims and prior authorization. In the context of requesting and sending attachments using attachment codes, attachments are limited to the documents defined by the LOINC Document Ontology and X12 attachment codes. When requesting and sending attachments using Questionnaire , attachments mean any additional information. |
web | x12.org |
This page documents a FHIR-based approach for requesting attachments for claims and prior authorization from a Provider.* This transaction is used for solicited
attachments and uses the combination of a Task-based CDex Task Attachment Request Profile
to request attachments and the
$submit-attachment
operation to submit the attachments to the Payer as documented in the Sending Attachments
page. It is intended to be compatible with the X12n 277 Request for Additional Information (RFAI) and 278 response transactions. For more information on X12 defined transactions, see X12 Transaction Sets
.
|
web | x12.org |
Requesting attachments using attachment codes defined by the LOINC Document Ontology or, for prior authorization, X12
PWK01 Report Type Codes is a HIPAA-based request model. The Payer communicates the missing information for a claim or prior authorization with these codes, which typically represent data in document form (e.g., a PDF or CCDA). The sequence diagram in Figure 15 below summarizes the interaction between the Payer and Provider to request and receive attachments using the combination of the CDex Task Attachment Request Profile
using attachment codes and the
$submit-attachment
operation.
|
web | x12.org | LOINC Attachment Code. For prior authorization, X12 PWK01 Report Type Codes may also be used. |
web | x12.org | The attachment code(s) for the requested documents. These codes are LOINC attachment codes or, for prior authorization, X12 PWK01 Report Type Codes |
web | x12.org |
The Payer supplies the attachment codes to communicate what attachments are needed. They may also provide the line item numbers
to match the attachment to a line item in the claim or prior authorization. This information is represented in the Task.input
"code" parameter. For example, the code snippet below shows a single request for line item 1 using a LOINC attachment code (for prior authorization, X12
PWK01 Report Type Codes may also be used). When submitting the attachments, the Provider returns the codes and line items to the Payer.
|
web | x12.org | This page documents a FHIR-based approach to sending attachments for claims or prior authorization directly to a Payer.* This transaction is used for both solicited and unsolicited attachments. It is intended to be compatible with the X12n 275 transaction, the X12 N 837I and 837P for claims purposes, and the 278 response for authorizations (for more information on X12 defined transactions, see X12 Transaction Sets ). Compatibility assumes that the appropriate identifiers are supported in the submission to facilitate the association of the attachment with the claim submission or authorization request. |
web | www.etsi.org |
The signature SHALL
include a "srCms"
signer commitments" header element for the Purpose(s) of the Signature (see JAdES-B-T
, page 17). The Purpose can be the action being attested to, or the role associated with the signature. The value shall come from ASTM E1762-95(2013).
|
web | en.wikipedia.org | Although self-signed certificates are used for these examples, they are not recommended for production systems. |
web | www.law.cornell.edu | "15 U.S. Code § 7006 - Definitions", LII / Legal Information Institute". Law.cornell.edu. Retrieved 2021-10-06. https://www.law.cornell.edu/uscode/text/15/7006#5 ↩ |
web | github.com | This is a Jupyter Notebook which uses openSSL, Python 3.7, and the Python jcs and jose libraries to create a JSON Web Signature (JWS) (see RFC 7515), attach it to a FHIR Bundle and validate it. Its source code be found here |
web | github.com | This is a Jupyter Notebook which uses openSSL, Python 3.7, and the Python jcs and jose libraries to create a JSON Web Signature (JWS)(see RFC 7515), attach it to a FHIR Bundle and validate it. Its source code be found here |
web | x12.org | Currently, claims and prior authorization requests can come through X12 transactions or portal submissions. Payers may need additional information or "attachments" from a Provider to determine if the service being billed (for claims) or requested (for prior authorizations) is supported by medical or policy benefits. In this guide, the term "attachments" includes a subset of additional information represented in document form defined by the LOINC Document Ontology and X12 . When requesting and sending attachments using Questionnaire , attachments mean any additional information. Attachments for claims or prior authorization can be divided into solicited and unsolicited workflows. The sections below document the differences and similarities between these workflows and define the CDex transactions that implementers can use for solicited and unsolicited prior authorization and claims attachments. See the Conforming to CDex Attachments for guidance on how systems define their support for each. |
POU-rollup-legend.svg |
POU-rollup.svg |
attachments-sequencediagram.svg |
attachments-task-Q-sequencediagram.svg |
attachments-task-Q-summary.svg |
cdex-request-attach-claim-flow.svg |
cdex-request-questionnaire-priorauth-flow.svg |
dtr-launch.svg |
fill-form-icon.svg |
gather-data-icon.svg |
jh-signature.jpg ![]() |
pas_cdex_decision_tree.svg |
profile-pyramid.svg |
request-attachments-cdex-sequencediagram.svg |
request-attachments-nonfhir-sequencediagram.svg |
search-sequencediagram.svg |
solicited-claim-flow.svg |
solicited-prior-auth-flow.svg |
task-sequencediagram.svg |
task-state-machine.svg |
taskbased-task-Q-sequencediagram.svg |
taskbased-task-Q-summary.svg |
tree-filter.png ![]() |
unsolicited-flow.svg |
workflow-overview.svg |
workflow-solicited-attachments.svg |
workflow-unsolicited-attachments.svg |