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 messageindicating the requets ahs 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".

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 insurere 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.

Dual Coding

Submit a claim using shadow billing when internal codes (agreed between payer and provider) must be reported alongside nphies-standard codes. Use the CodeableConcept data type’s ability to include multiple codings:

• The first coding SHALL represent the official nphies code.

• The second coding MAY include the internal payer-provider-agreed code.

This allows for transparent exchange while preserving internal business semantics.

Line Item Contents

TDB