The adoption of Prior Authorization is poised to revolutionize our healthcare system, potentially yielding billions in savings, enhancing patient care, and alleviating the workload of clinicians.
At the core of Prior Authorization are four pivotal implementation guides: Coverage Requirements Discovery (CRD), Clinical Data Exchange (CDex), Documentation Templates And Rules (DTR), and Prior Authorization (PAS).
Despite the richness of detail in these guides, their complexity can obfuscate the application of the prior auth workflow; often, the content overreaches beyond PAS-specific scenarios and lacks a cohesive, workflow-centric presentation complete with FHIR illustrations.
A successful implementation of prior auth would require the implementer to also understand FHIR in detail, CDS Hooks and CQL (Clinical Quality Language).
This informal guide endeavors to demystify the prior auth workflow, synthesizing the content across these guides into a streamlined, user-friendly manual complete with practical FHIR data exemplifications.
As with any document this complex, errors may exist. Please point them out to the author.
We will use an example of a doctor looking to order an MRI for a patient.
Pre-requisites
The health system is using an EMR such as Epic, Cerner, Allscripts etc. The health system has installed a SMART on FHIR app (Prior Auth App) that can handle prior authorization workflow and has registered CDS hooks to call when certain events happen in the EMR.
SMART on FHIR (or SMART) apps are apps you can install in any popular EMR. Like how you can install apps on your phone from the iPhone App Store.
CDS hooks is a technology that popular EMRs have where they can call an external app when certain events occur.
Payer has implemented a Payer FHIR API that can handle prior auth operations as described below.
Overview Diagram
Steps in the workflow
The following are the typical steps in the Electronic Prior Auth workflow:
Step 1: Doctor writes a new order in the EMR
Step 2: The EMR fires the “order-select” CDS hook to notify any registered software
Step 3: Prior Auth App receives the CDS hook
Step 4: Prior Auth App Fills Out the Questionnaire From EMR record
Step 5: Provider answers remaining questions and reviews the answers
Step 6: Prior Auth App generates the response to the questionnaire
Step 7: Provider submits a Prior Authorization Request to the Payer
Step 8: Payer Responds To Provider Prior Auth Request
Step 9: Payer Returns a Communication Request
Step 10: Payer returns a Task resource in the bundle
Step 11: Payer API returns Pending outcome
Step 12: Prior Auth stored in EMR
Step 1: Doctor writes a new order in the EMR
Doctor logs into their EMR and brings up this patient’s chart. They go the Orders section and create a new order for an MRI. They can choose from pre-defined order sets or write an order from scratch.
Step 2: The EMR fires the “order-select” CDS hook to notify any registered software
The order-select hook occurs after the clinician selects the order and before signing.
Another option is to wait till the doctor has signed the order (order-sign CDS hook).
An MRI order would be typically represented as a ServiceRequest in FHIR.
{
"resourceType": "ServiceRequest",
"id": "123",
"status": "draft",
"intent": "order",
"code": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
},
"subject": {
"reference": "Patient/example",
"display": "John Doe"
},
"requester": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"reasonCode": [
{
"text": "Headaches"
}
]
}
The EMR fires a CDS hook that contains this ServiceRequest:
{
"context": {
"userId": "PractitionerRole/123",
"patientId": "1288992",
"encounterId": "89284",
"selections": [
"ServiceRequest/123"
],
"draftOrders": {
"resourceType": "Bundle",
"entry": [
{
"resource": {
"resourceType": "ServiceRequest",
"id": "123",
"status": "draft",
"intent": "order",
"code": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
},
"subject": {
"reference": "Patient/example",
"display": "John Doe"
},
"requester": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"reasonCode": [
{
"text": "Headaches"
}
]
}
}
]
}
}
}
References:
https://www.hl7.org/fhir/us/davinci-crd/hooks.html
https://www.hl7.org/fhir/us/davinci-crd/hooks.html#order-select
Step 3: Prior Auth App receives the CDS hook
Prior Auth app looks up the payor for the patient and the corresponding endpoint to call for the API. (The Prior Auth app will need to register and maintain a directory of the endpoints for each payer).
Prior Auth App sends a ServiceRequest resource to the payor API to check if this service for this patient requires pre auth.
{
"resourceType": "ServiceRequest",
"id": "123",
"status": "draft",
"intent": "order",
"code": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
},
"subject": {
"reference": "Patient/example",
"display": "John Doe"
},
"requester": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"reasonCode": [
{
"text": "Headaches"
}
]
}
The Payor API replies with a ServiceRequest resource where it fills in the Coverage Information.
{
"resourceType": "ServiceRequest",
"id": "123",
"status": "active",
"intent": "order",
"code": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
},
"subject": {
"reference": "Patient/example",
"display": "John Doe"
},
"requester": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"reasonCode": [
{
"text": "Headaches"
}
],
"extension": [
{
"extension": [
{
"url": "coverage",
"valueReference": {
"reference": "Coverage/example"
}
},
{
"url": "covered",
"valueCode": "conditional"
},
{
"url": "pa-needed",
"valueCode": "satisfied"
},
{
"url": "doc-needed",
"valueCode": "admin"
},
{
"url": "doc-purpose",
"valueCode": "withclaim"
},
{
"url": "info-needed",
"valueCode": "performer"
},
{
"url": "billingCode",
"valueCoding": {
"system": "http://www.ama-assn.org/go/cpt",
"code": "77067"
}
},
{
"url": "reason",
"valueCodeableConcept": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp",
"code": "gold-card"
}
],
"text": "In-network required unless exigent circumstances"
}
},
{
"extension": [
{
"url": "code",
"valueCodeableConcept": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-crd/CodeSystem/temp",
"code": "auth-out-network-only"
}
]
}
},
{
"url": "value",
"valueBoolean": true
},
{
"url": "qualification",
"valueString": "Out-of-network prior auth does not apply if delivery occurs at a service site designated as 'remote'"
}
],
"url": "detail"
},
{
"url": "questionnaire",
"valueCanonical": "http://example.org/some-payer/Questionnaire/123|1.3.0"
},
{
"url": "response",
"valueReference": {
"reference": "#qr"
}
},
{
"url": "date",
"valueDate": "2019-02-15"
},
{
"url": "coverage-assertion-id",
"valueString": "12345ABC"
},
{
"url": "satisfied-pa-id",
"valueString": "XXYYZ"
},
{
"url": "contact",
"valueContactPoint": {
"system": "url",
"value": "http://some-payer.org/xyz-sub-org/get-help-here.html"
}
}
],
"url": "http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-coverage-information"
}
]
}
References:
https://www.hl7.org/fhir/us/davinci-crd/StructureDefinition-profile-servicerequest.html
https://build.fhir.org/ig/HL7/davinci-pas/StructureDefinition-profile-servicerequest.html
https://www.hl7.org/fhir/us/davinci-crd/StructureDefinition-ext-coverage-information.html
The Coverage Information extension is used by the payor to denote a few things:
Whether this service is covered
{
"url": "covered",
"valueCode": "conditional"
}
The possible values are “covered”, “not-covered” and “conditional” (https://www.hl7.org/fhir/us/davinci-crd/ValueSet-coverageInfo.html)
Conditional means the decision cannot be made without more information (more detailed code, service rendering information, etc.)
Whether Prior Auth is required for this service
{
"url": "pa-needed",
"valueCode": "performpa"
}
The possible values are (https://www.hl7.org/fhir/us/davinci-crd/ValueSet-coveragePaDetail.html): “no-auth”, “auth-needed”, “satisfied”, “performpa” and “conditional”.
no-auth: The ordered service does not require prior authorization.
auth-needed: The ordered service will require prior 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.
performpa: Prior authorization is needed for the service; however such prior authorization must be initiated by the performing (rather than ordering) provider.
Conditional: Decision cannot be made without more information (more detailed code, service rendering information, etc.)
If the value is no-auth or satisfied, then there is no need to do prior auth. We can skip the rest of this process.
If the value is “auth-needed” then we need to go through the prior auth process.
Whether a questionnaire needs to be filled out to submit with pre auth
{
"url": "questionnaire",
"valueCanonical": "http://example.org/some-payer/Questionnaire/123|1.3.0"
}
This specifies the FHIR Questionnaire that must be filled out and included in the prior authorization request.
There is other information returned in Coverage Information, but we will skip that to keep this document focused.
Step 4: Prior Auth App Fills Out the Questionnaire From EMR record
If we received a questionnaire then we should fill it out and include with our prior authorization request. (If we forget, the Payer API will send us the questionnaire again as a response to the actual prior auth request).
The Prior Auth app can download the FHIR Questionnaire from the provided URL (in this case: http://example.org/some-payer/Questionnaire/123|1.3.0).
To evaluate whether a given service will be covered, a payer may need to understand additional information about the patient. There are three main categories of such information:
- Attestation by the provider as to the patient’s need for a specific treatment or service. In this case, there is no specific clinical data required.
- Structured clinical data that is available through the EHR’s FHIR APIs. This might include laboratory results, scores or assessments, past medications or procedures represented using the appropriate US Core profiles.
- Information that is traditionally not structured, or where the review process is more involved and will not be performed in real time. In this use case, additional information may be in the form of progress notes, therapy notes, diagnostic reports, etc.
To make this process as automated as possible, the Payer API should return a CQL library that automatically fills in questions in category 2 from the patient record.
The FHIR Questionnaire sent by the Payer API can look like this:
{
"resourceType": "Questionnaire",
"id": "ASLPA1",
"url": "http://example.org/some-payer/Questionnaire/123",
"title": "MRI PreAuthorization",
"status": "active",
"description": "MRI PreAuthorization Form",
"item": [
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "History of Hypertension"
}
}
],
"linkId": "4",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-history-of-hypertension#Observation.value[x]",
"text": "History of Hypertension",
"type": "boolean"
},
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "History of Diabetes"
}
}
],
"linkId": "5",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-history-of-diabetes#Observation.value[x]",
"text": "History of Diabetes",
"type": "boolean"
},
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "Height"
}
}
],
"linkId": "7",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-height#Observation.value[x]",
"text": "Height (in inches)",
"type": "quantity"
},
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "Weight"
}
}
],
"linkId": "8",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-weight#Observation.value[x]",
"text": "Weight (in pounds)",
"type": "quantity"
}
]
}
References:
https://hl7.org/fhir/R4B/questionnaire.html
This questionnaire consists of four questions:
- Whether patient has a history of hypertension
- Whether patient has a history of diabetes
- Height of the patient
- Weight of the patient
The data to answer all four of these questions already exists in the EMR. So it seems wasteful to ask the doctor to dig through the EMR and find this information.
The CQL standard (https://cql.hl7.org/) allows us to provide machine executable logic that a CQL engine can use to read the data from EMR and fill in these values automatically. Let’s look at the question for height:
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "Height"
}
}
],
"linkId": "7",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-height#Observation.value[x]",
"text": "Height (in inches)",
"type": "quantity"
}
The extension of “text/cql-identifier” tells the Prior Auth App that this answer can be automatically filled by CQL logic. A CQL identifier is plain text, containing only the name of a top-level CQL construct such as an expression definition.
The CQL logic to find height from the FHIR patient record is specified in the definition field:
http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-height#Observation.value[x]
This means that the Prior Auth App should download the CQL library from the url: http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-height. Prior Auth App should have its CQL engine run this logic and then find the value of the variable “Observation.value” and use that as the answer to the height question.
Here’s an example CQL library that can find height in a patient record:
define Observation:
from Observation O
where O.code.coding.code = '8302-2' // LOINC code for body height
and O.status = 'final'
order by O.effectiveDateTime desc
return O.valueQuantity
This CQL should be run restricted to the current patient record. This CQL returns the latest height reading for this patient.
Now let’s look at the example of the question about whether the patient has a history of hypertension.
{
"extension": [
{
"url": "http://hl7.org/fhir/uv/sdc/StructureDefinition/sdc-questionnaire-initialExpression",
"valueExpression": {
"language": "text/cql-identifier",
"expression": "History of Hypertension"
}
}
],
"linkId": "4",
"definition": "http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-history-of-hypertension#Observation.value[x]",
"text": "History of Hypertension",
"type": "boolean"
}
Again, the extension of “text/cql-identifier” tells us that we can use the provided CQL logic to automatically fill this answer.
The “definition” field tells us what CQL library to download: http://example.org/sdh/dtr/aslp/StructureDefinition/aslp-history-of-hypertension.
Here’s an example of what this CQL library can look like:
define HasHypertensionHistory:
exists (from Condition C
where C.code.coding.code in { '38341003' } // SNOMED CT code for hypertension
and C.clinicalStatus.coding.code = 'resolved' or C.clinicalStatus.coding.code = 'active')
This is a very simple CQL example that uses a single SnoMED code. In real world, you would refer to an existing value set from VSAC like:
library RetrieveHypertensionHistory version '1.0'
using FHIR version '4.0.0'
include FHIRHelpers version '4.0.0' called FHIRHelpers
valueset "Hypertension": 'http://cts.nlm.nih.gov/fhir/ValueSet/{ValueSetOID}'
define HasHypertensionHistory:
exists (from Condition C
where C.code in "Hypertension")
Now we’ve seen how the Payer API can specify CQL to prefill the answers.
Step 5: Provider answers remaining questions and reviews the answers
Prior Auth App then takes any questions that don’t have the CQL logic and presents them to the doctor to answer.
The doctor types in the answers and (optionally) can attach any documents requested.
The doctor then reviews all the answers including the ones automatically calculated by CQL and accepts them or modified them.
Step 6: Prior Auth App generates the response to the questionnaire
The Prior Auth App takes the answers and creates a FHIR QuestionnaireResponse (https://hl7.org/fhir/R4B/questionnaireresponse.html) resource with all the answers.
{
"resourceType": "QuestionnaireResponse",
"id": "response123",
"questionnaire": "http://example.org/some-payer/Questionnaire/123",
"status": "completed",
"subject": {
"reference": "Patient/example"
},
"authored": "2024-03-27T00:00:00Z",
"author": {
"reference": "Practitioner/example"
},
"item": [
{
"linkId": "4",
"text": "History of Hypertension",
"answer": [
{
"valueBoolean": false
}
]
},
{
"linkId": "5",
"text": "History of Diabetes",
"answer": [
{
"valueBoolean": true
}
]
},
{
"linkId": "7",
"text": "Height (in inches)",
"answer": [
{
"valueQuantity": {
"value": 68,
"unit": "in",
"system": "http://unitsofmeasure.org",
"code": "in"
}
}
]
},
{
"linkId": "8",
"text": "Weight (in pounds)",
"answer": [
{
"valueQuantity": {
"value": 150,
"unit": "lb",
"system": "http://unitsofmeasure.org",
"code": "lb"
}
}
]
}
]
}
Step 7: Provider submits a Prior Authorization Request to the Payer
Now the Prior Auth App has the QuestionnaireResponse resource filled out and approved by the doctor. It can now submit the full request to the payer API for prior auth.
The request for prior auth is sent as a FHIR Claim bundle to the $submit endpoint on the payer API.
{
"resourceType": "Bundle",
"entry": [
{
"resource": {
"resourceType": "Claim",
"id": "claim123",
"status": "active",
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional",
"display": "Professional"
}
]
},
"patient": {
"reference": "Patient/example",
"display": "John Doe"
},
"created": "2024-03-27",
"provider": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"diagnosis": [
{
"sequence": 1,
"diagnosisCodeableConcept": {
"text": "Headaches"
}
}
],
"item": [
{
"sequence": 1,
"careTeamSequence": [
1
],
"productOrService": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
},
"servicedDate": "2024-03-27",
"unitPrice": {
"currency": "USD",
"value": "Amount"
},
"quantity": {
"value": 1
}
}
],
"careTeam": [
{
"sequence": 1,
"provider": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
}
}
],
"supportingInfo": [
{
"sequence": 1,
"category": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "additionalInformation"
}
]
},
"valueReference":"QuestionnaireResponse/response123"
}
]
}
},
{
"resource": {
"resourceType": "QuestionnaireResponse",
"id": "response123",
"questionnaire": "http://example.org/some-payer/Questionnaire/123",
"status": "completed",
"subject": {
"reference": "Patient/example"
},
"authored": "2024-03-27T00:00:00Z",
"author": {
"reference": "Practitioner/example"
},
"item": [
{
"linkId": "4",
"text": "History of Hypertension",
"answer": [
{
"valueBoolean": false
}
]
},
{
"linkId": "5",
"text": "History of Diabetes",
"answer": [
{
"valueBoolean": true
}
]
},
{
"linkId": "7",
"text": "Height (in inches)",
"answer": [
{
"valueQuantity": {
"value": 68,
"unit": "in",
"system": "http://unitsofmeasure.org",
"code": "in"
}
}
]
},
{
"linkId": "8",
"text": "Weight (in pounds)",
"answer": [
{
"valueQuantity": {
"value": 150,
"unit": "lb",
"system": "http://unitsofmeasure.org",
"code": "lb"
}
}
]
}
]
}
}
]
}
This FHIR Bundle consists of two resources. First is the FHIR Claim that defines the service(s) that the doctor is trying to get pre-authorization for. The second is the FHIR QuestionnaireResponse that contains the answers. The “supportingInfo” field in the Claim refers to the QuestionnaireResponse.
"supportingInfo": [
{
"sequence": 1,
"category": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "additionalInformation"
}
]
},
"valueReference":"QuestionnaireResponse/response123"
}
]
}
Step 8: Payer Responds To Provider Prior Auth Request
Payer API will respond with a FHIR ClaimResponse resource.
{
"resourceType": "ClaimResponse",
"id": "response123",
"status": "active",
"use": "preauthorization",
"patient": {
"reference": "Patient/example",
"display": "John Doe"
},
"created": "2024-03-28",
"requestor": {
"reference": "Practitioner/example",
"display": "Dr. Jane Smith"
},
"request": {
"reference": "Claim/claim123"
},
"outcome": "complete",
"insurer": {
"reference": "Organization/insurance-company",
"display": "Example Insurance Company"
},
"item": [
{
"itemSequence": 1,
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemRequestedServiceDate",
"valuePeriod": {
"start": "2005-05-02",
"end": "2005-06-02"
}
},
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthIssueDate",
"valueDate": "2005-05-02"
},
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthPeriod",
"valuePeriod": {
"start": "2005-05-02",
"end": "2005-06-02"
}
},
{
"extension": [
{
"url": "provider",
"valueReference": {
"reference": "Practitioner/ReferralPractitionerExample"
}
}
],
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemAuthorizedProvider"
},
{
"extension": [
{
"url": "productOrServiceCode",
"valueCodeableConcept": {
"coding": [
{
"system": "http://www.ama-assn.org/go/cpt",
"code": "70551",
"display": "Magnetic resonance (e.g., proton) imaging, brain (including brain stem); without contrast material"
}
],
"text": "MRI of the brain without contrast"
}
},
{
"url": "unitPrice",
"valueMoney": {
"value": 100,
"currency": "USD"
}
},
{
"url": "quantity",
"valueQuantity": {
"value": 1
}
}
],
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemAuthorizedDetail"
}
],
"noteNumber": [
1
],
"adjudication": [
{
"extension": [
{
"extension": [
{
"url": "number",
"valueString": "AUTH0001"
},
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewActionCode",
"valueCodeableConcept": {
"coding": [
{
"system": "https://codesystem.x12.org/005010/306",
"code": "A1",
"display": "Certified in total"
}
]
}
}
],
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction"
}
],
"category": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/adjudication",
"code": "submitted"
}
]
}
}
],
"total": {
"category": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/adjudication",
"code": "total",
"display": "Total"
}
]
},
"amount": {
"value": "Total approved amount",
"currency": "USD"
}
},
"payment": {
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/payment-type",
"code": "complete",
"display": "Complete"
}
]
},
"amount": {
"value": "Payment amount",
"currency": "USD"
},
"date": "2024-03-29"
},
"processNote": [
{
"number": 1,
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/note-type",
"code": "display",
"display": "Display"
}
]
},
"text": "Additional information about the claim processing."
}
]
}
]
}
The “outcome” field value of “completed” tells us that the payer has completed the pre auth process.
"outcome": "complete",The other possible values are queued, error and partial.
If the value is “queued” (the Claim/Pre-authorization/Pre-determination has been received but processing has not begun) or “partial” (No errors have been detected in the Claim and some of the adjudication has been performed) then the Prior Auth App should poll the Payer API until it receives a FHIR ClaimResponse with another status.
If the value is “error” (One or more errors have been detected in the Claim) then the Prior Auth App should read the “error” field and take appropriate action to resolve the error.
The data in the “item” field tells us that whether pre auth was approved for each item on the claim.
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthIssueDate",
"valueDate": "2005-05-02"
}
If the pre-auth was approved or denied, then we are done with the process.
However, if the Payer returns a CommunicationRequest or Task with the response bundle then it means the Payer wants the provider to provide something more. This is typically another questionnaire to fill out or maybe we never sent the response to the questionnaire we received in coverage request above.
Step 9: Payer Returns a Communication Request
CommunicationRequest is returned in the “communicationRequest” property of ClaimResponse.
{
"resourceType": "CommunicationRequest",
"id": "CommunicationRequestExample",
"status": "active",
"category": [
{
"coding": [
{
"system": "https://codesystem.x12.org/005010/755",
"code": "15",
"display": "Justification for Admissions"
}
]
}
],
"payload": [
{
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceLineNumber",
"valuePositiveInt": 1
},
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-communicatedDiagnosis",
"valueCodeableConcept": {
"coding": [
{
"system": "http://hl7.org/fhir/sid/icd-10-cm",
"code": "G89.4"
}
]
}
},
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-contentModifier",
"valueCodeableConcept": {
"coding": [
{
"system": "http://loinc.org",
"code": "18804-5"
}
]
}
}
],
"contentString": "Please provide further justification as interested."
}
]
}
If a CommunicationRequest is received, then the Prior Auth should show the contents to the provider to have them take the appropriate action.
Step 10: Payer returns a Task resource in the bundle
Task is returned in the bundle that includes ClaimResponse. Typically the task is to fill out a questionnaire.
{
"resourceType": "Task",
"id": "AdditionalInformationTaskExample",
"identifier": [
{
"system": "http://example.org/ITEM_TRACE_NUMBER",
"value": "1122334"
}
],
"status": "requested",
"intent": "order",
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "attachment-request-code"
}
]
},
"for": {
"reference": "Patient/BeneficiaryExample"
},
"requester": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "789312"
}
},
"owner": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "789312"
}
},
"reasonCode": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "priorAuthorization"
}
]
},
"reasonReference": {
"reference": "Claim/MedicalServicesAuthorizationExample"
},
"input": [
{
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-paLineNumber",
"valueInteger": 1
}
],
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "questionnaires-needed"
}
]
},
"valueCanonical": "http://example.org/some-payer/Questionnaire/123|1.3.0"
}
]
}
The Prior Auth app should now go through the same process in downloading the questionnaire and filling it out.
"input": [
{
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-paLineNumber",
"valueInteger": 1
}
],
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASTempCodes",
"code": "questionnaires-needed"
}
]
},
"valueCanonical": "http://example.org/some-payer/Questionnaire/123|1.3.0"
}
]It should then have the doctor review the automatically filled answers and answer any remaining questions.
Step 11: Payer API returns Pending outcome
If in step 8, the Payer API returned an outcome of “partial” then it means the Prior Auth App should periodically poll the payer API to check on the status of the prior auth.
The Prior Auth App does this by sending a ClaimInquiry resource to the $inquire endpoint on the Payer API. The ClaimInquiry resource is the same as the Claim resource that was submitted in Step 7.
The response is a ClaimInquiryResponse which is essentially the same as the ClaimResponse resource in Step 8 and can be processed the same way.
Step 12: Prior Auth stored in EMR
The Prior Auth App can now store the status of prior auth in the EMR so there is a record of whether the prior auth was approved or rejected.