| Lvl | Code | Display | Definition | Not Selectable |
| 1 |
conditional |
Conditional |
There is the potential for information requirements from a participant type not listed. However, a decision on whether there in fact are additional information requirements cannot be made without more information (more detailed code, service rendering information, etc.) |
|
| 1 |
covered |
Covered |
Regular coverage applies |
|
| 1 |
not-covered |
Not covered |
No coverage or possibility of coverage for this service) |
|
| 1 |
no-auth |
No Prior Authorization |
The ordered service does not require prior authorization |
|
| 1 |
auth-needed |
Prior Authorization Needed |
The ordered service will require prior authorization |
|
| 2 |
performpa |
Performer Prior Authorization |
Prior authorization is needed for the service, however such prior authoriation must be initiated by the performing (rather than ordering) provider. |
|
| 1 |
satisfied |
Authorization Satisfied |
While prior authorization would typically be needed, the conditions evaluated by prior authorization have already been evaluated and therefore prior authorization can be bypassed |
|
| 1 |
clinical |
Clinical Documentation |
Details most likely to originate from a clinician are required to satisfy additional documentation requirements, determine coverage and/or prior auth applicability - e.g. via DTR by clinician. Indicates that the CRD client should expose the need to launch DTR to clinical users. |
|
| 1 |
admin |
Administrative Documentation |
Administrative details not likely to require clinical expertise are needed to satisfy additional documentation requirements, determine coverage and/or prior auth applicability - e.g. via DTR by back-end staff. Indicates that while the CRD client might expose the ability to launch DTR as an option for clinical users, it should be clear that clinical input is not necessary and deferring the use of DTR to back-end staff is perfectly appropriate. Some CRD clients might be configured (based on provider preference) to not even show clinicians the option to launch. |
|
| 1 |
patient |
Administrative & clinical doc |
Details most likely to originate from the patient or their personal representative (e.g. parent, spouse, etc.) are required to satisfy additional documentation requirements, determine coverage and/or prior auth applicability. For example, information about household composition, accessibility considerations, etc. This should be used when the data needs to come from the patient themselves, rather than a clinician's assessment of the patient |
|
| 1 |
_docReason |
Additional Information Purposes |
A collector for codes representing different reasons for capturing additional information |
true |
| 2 |
withpa |
Include in prior authorization |
The information in this QuestionnaireResponse should be packaged into a Bundle and submitted as part of (or in association with) a prior authorization for the associated request resource(s). |
|
| 2 |
withclaim |
Include with claim |
The information in this QuestionnaireResponse should be packaged into a Bundle and submitted as part of (or in association with) the insurance claim for the services ordered by the associated request resource(s). |
|
| 2 |
withorder |
Include with order |
The information in this QuestionnaireResponse should be packaged into a Bundle and submitted along with (or referenced as supporting information to) the associated request resource(s) when transmitting the order to the fulfilling system. |
|
| 2 |
retain-doc |
Medical necessity |
The information in this QuestionnaireResponse should be retained within the EHR as supporting evidence of the medical necessity of the associated request resource(s). |
|
| 1 |
performer |
Performer Needed |
Information about who (specifically, or at least performer type and affiliation) is necessary to make a determination of coverage and/or prior auth expectations |
|
| 1 |
location |
Location Needed |
Information about where (specific clinic/site or organization) is necessary to make a determination of coverage and/or prior auth expectations |
|
| 1 |
timeframe |
Timeframe Needed |
Information about when the service will be performed that is more granular than the order effective period is necessary to make a determination of coverage and/or prior auth expectations |
|
| 1 |
contract-window |
New Contract Window |
The target performance time for the event falls outside the contract window for the patient's current coverage. Information will not be available until a contract is in place covering the service time period |
|
| 1 |
detail-code |
Detail code |
The ordered code is at too high a level of granularity to make decisions about coverage/pa/etc. Can only be present if something is 'conditional' |
|
|
Propose a change