Healthcare Financial Services IG Edition 1 - Local Development build (v0.3.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Use Cases

Overview

This implementation guide provides the detailed exchanges and business guidance to support the many electronic exchanges between healthcare providers (HCP) and insurers (HIC) via the nphies central clearinghouse system. In the sections which follow the business use cases for each of these exchanges will be presented and text or links to technical artifacts provided along with use case specific guidance.

Typical Use Case Structure

While the sections to follow will provide details for specific use cases, this section will outline the type and purpose of the information provided for each use case.

1. [Required] A graphic depicting the actors and the workflow of the exchanges.
2. [Required] A textual description of the flows providing both 'happy path' and error handling guidance.
3. [Required] The high-level structure of the messages to be exchanged including links to key (focal) resource profiles.
4. [Optional] Any special data element or processing requirements.
5. [Required] Links to example messages and key extension profiles.
6. [Required] Use case specific error handling guidance or links to common error handling guidance.

Acknowledgement Message

An Acknowledgement Message is a simple response to requests which only need a response to indicate receipt of a valid and processable message, should processing of any kind be required, or to indicate errors in the construction or contents of a message.

While most messages are provided within the usecase to which they apply, the Acknowledgement Message is provided here as it is referenced by several usecases including: Advanced Authorization; Error Notice; Information Request; Information Submission; Payment Reconciliation; and Payment Notification.

The key resources for the message are provided below and all require nphies-profiled resources as provided in the Artifacts. Note: the MessageHeader resource must be the first .entry in the bundle and any other resources may follow in any order.

Nphies Bundle (.type = message )
  Nphies MessageHeader (.eventCoding = acknowledgement)
  [Nphies OperationOutcome (if errors exist)]

General Guidance

Messages

• nphies Pending Logic: If nphies is unable to deliver a request message to the insurer or TPA, the message will be pended for later delivery unless it is a real-time only message. A response will be returned to the provider indicating that the request was received without detectable errors and will be forwarded to the insurer or TPA when the exchange issue is resolved.

• Timeout Handling: If nphies is not able to deliver the request message to the insurer or TPA within one minute, or encounters an exchange error, then a response message indicating the request has been pended (queued) or error response will be generated. The response will include a bundle.meta.tag to indicate the message was issued by nphies (see Meta Tag: nphies-generated).

• Polling for Queued Responses: If a message is received from an insurer or TPA, either a deferred response due to manual adjudication or an unsolicited message such as a supporting Information Request or payment Reconciliation, and the message does not contain detectable errors, it is stored (pended or queued) by nphies. Providers may retrieve the message via Polling at their convenience.

SupportingInfo

Supporting information, typically clinical but may be administrative, may be supplied by providers in the Claim and Authorization messages using the .supportInfo data structure and supplied by insurers in Advanced Authorization messages using the supportingInfo extension. In all cases the type of information being supplied is provided as a code in the category element. Within Claim and Authorization profiles the information requirements for different categories are specified by slicing. Given that slicing is not available for extensions this guide provides the information requirements for the supportingInfo extension in profiles of that extension which are listed in the Profile column of the table below.

Notes on Supporting Information:

• Admission weight:
• admission weight is mandatory when age is less than 365 days.
• Age is calculated as follows: encounter start date - patient birth date.
• Patient.birthdate shall be on or before Encounter.period.start when encounter.period.start exists.
• Patient.birthdate shall be on or before currentDate and after 1900-01-01.
• Admission weight shall be only present when claim type = institutional and claim subtype = IMP.
• Morphology:
• If principal or secondary diagnosis in a claim or prior authorization belongs to morphology diagnosis list then supporting info "morphology" SHALL be provided.
• Vital-sign-weight, Vital-sign-systolic, Vital-sign-diastolic, Vital-sign-height, Temperature, Pulse, Oxygen-saturation, Respiratory-rate:
• Provide a value or an absence reason - for reason codes see Code Systems.
• Investigation result:
• If principal or secondary diagnosis in a claim or prior authorization belongs to morphology diagnosis list then supporting info "morphology" SHALL be provided.
• An attachment SHALL be provided when .Code = "IRA".
• A string (Text) SHALL be Provided when .Code = "other".

Newborn Handling

Newborns usually do not have their own insurance (coverage) from the date of birth to about 30 days, so the eligibility check, prior authorizations, and claim for services provided to the newborn will include the newborn’s patient (Patient instance) information and will use the mother's insurance (Coverage instance). However, because the newborn's gender and date of birth in the patient resource do not match that of the insurer-saved subscriber, the newborn extension is specified in the eligibility, approval, or claim message to notify the insurer that the message is for the newborn.

The eligibility message only requires the addition of the newborn extension, while prior authorizations and claims require the birth-weight to be included in the supportingInfo section for newborn encounter - i.e. the birth encounter only. For all other claims and authorizations for newborns only the newborn extension is required.

Accidents

The Claim.accident provides the details of an accident which resulted in injuries which required the products and services listed in the claim or authorization.

Accident validation rules:

• Claim.accident with Claim.accident.type = "WPA" SHALL exist if at least one diagnosis code is from the Work Related Diagnosis list when Claim.use = "claim" or "preauthorization".

• Claim.accident with Claim.accident.type = "MVA" SHALL exist if at least one diagnosis code is from the RTA diagnosis list when Claim.use = "claim" or "preauthorization".

Authorization and Claim Adjudication

Once submitted, the insurer adjudicates the request and responds with a response message, which may be:

• an error response (.outcome = 'error') and content in the .error element;
• a queued response (.outcome = 'queued') meaning the request is held for deferred processing;
• a partial adjudication (.outcome = 'partial') indicating that some items have been processed which others have not. The adjudication provided is indicative but may be subject to change when the adjudication is complete; or
• a complete adjudication (.outcome = 'complete') indicating the processing of the request is complete.

If the .outcome is queued or partial the response may include a CommunicationRequest Resource specifying the information needed by the insurer or TPA to complete the processing. Alternately the insurer may send a separate Information Request to request additional information. Providers may also send an unsolicited Information Submission if they have any reason to sent supporting information after sucessfully submitting a request message as long has the message didn't receive errors and has not yet been fully processed.

The AdjudicationOutcome extension, which may appear both at the header and line item level of the response, provides one of the adjudication status codes:

• Full approval - the item has been approved as submitted;
• Partial approval - the item has been approved as less than the amount submitted but not zero; or
• Denial - the item has not been approved and zero will be paid for this item.

Adjudication and Rejection Reasons

Adjudication reasons (Rejection Reasons) are used to provide detailed explanations for the outcome of an adjudication process.

The rejection codes categorization can be summarized in nphies as per the below five categories:

Responding to Partial Approvals and Rejections

If the payer partially approves or rejects a service due to insufficient information, then the provider may send to the payer an Information Submission (Communication) which references the authorization or claim and includes the supporting information. The payer may then issue a new ClaimResponse along with a reissue-reason code, with their revised adjudication.

Dual Coding

There are circumstances when it is necessary to provide more than one code for a concept. For example, when submitting line items on claims and authorizations where both the Saudi Billing System code and the provider's interanl code must be submitted given that the provider-payer contract may still be based on the provider's interanl code. These situations are adressed by using the CodeableConcept data type's ability to include multiple codings:

• The first coding SHALL represent the official code and will be from the required binding ValueSet.

• The second coding MAY include the alternate code such as an internal payer-provider-agreed code.

This allows for transparent exchange while preserving internal business semantics.

Similarly, this feature may be used in the future to transition from one Code System to another as standards requirements evolve. Note that generally it is not permitted to have multiple codes from the same Code System as each code is required to convey the same fundamental concept and Code Systems normally just have one code for each unique concept.

Line Item Contents

There are a number of data elements provided within claims and aautorizations to express the costs associated with products and services being claim or authorized. The table below summarizes the key elemenst and their rationship to the overall cost as expressed in the equation:

net = (quantity * unitPrice * factor) + tax