Unattributed Code Systems

Copyright Fragment

This fragment is available on ImplementationGuide-hl7.fhir.us.davinci-cdex.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

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).
  • The "srCms" header SHALL contain an "id": "urn:oid:1.2.840.10065.1.12.1.5" (Verification Signature)
  • The Signature.type.code elements SHALL contain the same values as the "srCms" header ids.
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.

Internal Images

POU-rollup-legend.svg
POU-rollup-legend.svg
POU-rollup.svg
POU-rollup.svg
attachments-sequencediagram.svg
attachments-sequencediagram.svg
attachments-task-Q-sequencediagram.svg
attachments-task-Q-sequencediagram.svg
attachments-task-Q-summary.svg
attachments-task-Q-summary.svg
cdex-request-attach-claim-flow.svg
cdex-request-attach-claim-flow.svg
cdex-request-questionnaire-priorauth-flow.svg
cdex-request-questionnaire-priorauth-flow.svg
dtr-launch.svg
dtr-launch.svg
fill-form-icon.svg
fill-form-icon.svg
gather-data-icon.svg
gather-data-icon.svg
jh-signature.jpg
jh-signature.jpg
pas_cdex_decision_tree.svg
pas_cdex_decision_tree.svg
profile-pyramid.svg
profile-pyramid.svg
request-attachments-cdex-sequencediagram.svg
request-attachments-cdex-sequencediagram.svg
request-attachments-nonfhir-sequencediagram.svg
request-attachments-nonfhir-sequencediagram.svg
search-sequencediagram.svg
search-sequencediagram.svg
solicited-claim-flow.svg
solicited-claim-flow.svg
solicited-prior-auth-flow.svg
solicited-prior-auth-flow.svg
task-sequencediagram.svg
task-sequencediagram.svg
task-state-machine.svg
task-state-machine.svg
taskbased-task-Q-sequencediagram.svg
taskbased-task-Q-sequencediagram.svg
taskbased-task-Q-summary.svg
taskbased-task-Q-summary.svg
tree-filter.png
tree-filter.png
unsolicited-flow.svg
unsolicited-flow.svg
workflow-overview.svg
workflow-overview.svg
workflow-solicited-attachments.svg
workflow-solicited-attachments.svg
workflow-unsolicited-attachments.svg
workflow-unsolicited-attachments.svg