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

Message Exchange

There are four patterns of message exchange used within this guide:

1. Full cycle - messages sent from the HCP through nphies to the HIC which validates and processes or stores for deferred processing and returns a response message through nphies and it, or a nphies generated response, is passed back to the HCP all within the same communication session.
2. HCP to nphies - messages are sent by the HCP to nphies for validation and processing. Typically used for HCP polling and notices.
3. HIC to nphies - messages are sent by the HIC to nphies for validation and processing. Typically used for deferred responses and insurer-initiated requests or notices.
4. nphies to HIC - messages are sent by the nphies to HIC for validation and processing. Typically used for delivering error notices regarding prior message exchanges.

Constraints:

Where multiple constraints apply, such as claim batches where the contain message count and overall message length both apply, all constraints must be met.

• Communication Sessions SHALL have a maximum ‘up time’ of 60 seconds.
• Messages SHALL have a maximum length of 10 MB.
• Claim batches SHALL have a maximum of 200 claims request messages.
• Poll requests SHALL request and Poll responses may return a maximum of 100 messages.

Full Cycle Pattern

The above exchange is initiated by the Provider where the key business activity occurs at the HIC/TPA.

Steps:

1. The Sender (HCP) opens an HTTPS session with the Receiver’s (nphies) $process-message endpoint and the parties exchange and validate certificates. If validation fails the session is closed and the exchange is terminated, otherwise the Sender sends the request message to the Receiver.
2. The Receiver validates the form and content of the message.
   • If the message is not valid then the Receiver generates an error message, either in the appropriate business response form of the request or an OperationOutcome resource, and proceeds to Step 6.
   • If the message is valid then it is stored and registered in the queue, and:
   • if the target Receiver of the message, the insurer or TPA, is not online or the message cannot be delivered to them in a timely manner then the message remains in the queue and nphies generates a response message for the Sender (HIC) and proceeds to Step 6.
   • otherwise the message is readied for delivery.
3. The Sender (nphies) opens an HTTPS session with the Receiver’s (HIC) $process-message endpoint and the parties exchange and validate certificates. If validation fails the session is closed and the exchange is terminated, otherwise the Sender sends the request message to the Receiver.
4. The Receiver (HIC) SHALL process the request-message and return either:
   • a business response-message containing one of: validation errors; acknowledgement of receipt; partial or full processing results; or
   • an OperationOutcome indicating the processing/validation issue. Note that the likelyhood of this type of response is extremely low given the validation which occurs at the clearinghouse.
5. The Receiver (nphies) validates the response-message and
   • If the message is valid then it is stored, registered, in the queue and proceeds to Step 6.
   • If the message is not valid then:
   • the Receiver (nphies) generates and queues an error-notice message for the Sender (HIC), and
   • generates an error message for the Sender (HCP), either in the appropriate business response form of the request or an OperationOutcome resource, and proceeds to Step 6.
6. The Receiver (nphies) returns the response message to the Sender (HCP), removes the message registration from the queue and closes the exchange session. In the event that an error occurs during this stage the response-message remains registered in the queue and can then be retrieved by the Sender (HCP) either by resending the original request-message or by Polling.

Exchanges Using the Full Cycle Pattern

HCP to nphies Pattern

The above exchange is initiated by the Provider where the key business activity occurs within nphies.

Steps:

1. The Sender (HCP) opens an HTTPS session with the Receiver’s (nphies) $process-message endpoint and the parties exchange and validate certificates. If validation fails the session is closed and the exchange is terminated, otherwise the Sender sends the request message to the Receiver.
2. The Receiver validates the form and content of the message and processes the message.
   • If the message is not valid then the Receiver generates an error message, either in the appropriate business response form of the request or an OperationOutcome resource, and proceeds to Step 3.
   • The Receiver (nphies) SHALL process the request-message and return either:
   • a business response-message containing one of: validation errors; acknowledgement of receipt; partial or full processing results; or
   • an OperationOutcome indicating the processing/validation issue. Note that the likelyhood of this type of response is extremely low given the validation which occurs at the clearinghouse.
3. The Receiver (nphies) returns the response-message to the Sender (HCP), removes the message registration from the queue and closes the exchange session. In the event that an error occurs during this stage the response-message remains registered in the queue and can then be retrieved by the Sender (HCP) either by resending the original request-message or by Polling.

Exchanges Using the HCP to nphies Pattern

HIC to nphies Pattern

The above exchange is initiated by the Insurer where the key business activity occurs within nphies.

Steps:

1. The Sender (HIC) opens an HTTPS session with the Receiver’s (nphies) $process-message endpoint and the parties exchange and validate certificates. If validation fails the session is closed and the exchange is terminated, otherwise the Sender sends the request message to the Receiver.
2. The Receiver validates the form and content of the message and processes the message.
   • If the message is not valid then the Receiver generates an error message, either in the appropriate business response form of the request or an OperationOutcome resource, and proceeds to Step 3.
   • The Receiver (nphies) SHALL process the request-message and return either:
   • a business response-message containing one of: validation errors; acknowledgement of receipt; partial or full processing results; or
   • an OperationOutcome indicating the processing/validation issue. Note that the likelyhood of this type of response is extremely low given the validation which occurs at the clearinghouse.
3. The Receiver (nphies) returns the response message to the Sender (HIC), removes the message registration from the queue and closes the exchange session. In the event that an error occurs during this stage the response-message remains registered in the queue and issues can be resolved and re-transmitted by nphies. If appropriate the response-message can then be retrieved by the HCP by Polling.

Exchanges Using the HIC to nphies Pattern

nphies to HIC Pattern

The above exchange is initiated by the Insurer where the key business activity occurs within HIC.

Steps:

1. The Sender (nphies) opens an HTTPS session with the Receiver’s (HIC) $process-message endpoint and the parties exchange and validate certificates. If validation fails the session is closed and the exchange is terminated, otherwise the Sender sends the request message to the Receiver.
2. The Receiver validates the form and content of the message and processes the message.
   • If the message is not valid then the Receiver generates an error message, either in the appropriate business response form of the request or an OperationOutcome resource, and proceeds to Step 3.
   • The Receiver (HIC) SHALL process the request-message and return either:
   • a business response-message containing one of: validation errors; acknowledgement of receipt; partial or full processing results; or
   • an OperationOutcome indicating the processing/validation issue. Note that the likelyhood of this type of response is extremely low given the validation which occurs at the clearinghouse.
   • The Receiver (HIC) returns the response message to the Sender (nphies) and closes the exchange session. In the event that an error occurs during this stage the response-message remains registered in the queue and issues can be resolved and new messages transmitted by nphies.
3. The Sender (nphies) removes the message from the queue if no exchange error has occurred.

Exchanges Using the HIC to nphies Pattern

Message Initiation and Receipt

Message initiated by HCP

When an HCP has a message to send to nphies or to an HIC then the HCP shall initiate a message exchange by calling nphies’ $process-request endpoint with the message to be sent to nphies and nphies SHALL respond with a response message indicating the successful receipt of the message or a processing response or the existence of errors.

Where appropriate the HIC SHALL respond in realtime with an appropriate business response indicating errors, request message receipt or with the complete business response. When the HIC is unable to respond, if appropriate, nphies SHALL issue a message on their behalf and store and forward the request message to the HIC later.

Message initiated by HIC

When a HIC has a message to send to nphies or HCP that is not in immediate response to a request from nphies, e.g. deferred response to a prior authorization; deferred adjudication to a claim; or communication request; payment reconciliation, then the HIC shall initiate a message exchange by calling nphies’ $process-request end-point with the message (for example: claim-response, priorauth-response, advanced-authorization) to be sent to nphies and nphies SHALL respond with a response message indicating the successful receipt of the message or the existence of errors. If valid then nphies SHALL queue the message for later retrieval by the HCP via polling.

Messages Received by HIC

HICs SHALL expose a static endpoint to receive nphies messages. HICs SHALL expose one RESTful API endpoint and service to receive nphies FHIR R4 messages, for example at ‘https://InsuranceCompany.sa/api/fs/fhir/$process-message’. HICs SHALL expose another RESTful API endpoint to enable nphies to validate the HICs online availability. The HIC API SHALL do the following:

• Ensure Trusted communication – private key encryption using mutual certificates to allow senders and receivers to identify and authorize the communication;
• Support the exchange of messages using the HTTP Request-Response paradigm; and,
• Maintain the agreed behaviour for the exchange and processing of messages.

Messages Received by NPHIES

nphies provides a messaging endpoint, for example at ‘https://nphies.sa/api/fs/fhir/$process-message’. nphies API SHALL do the following:

• Ensure Trusted communication – private key encryption using mutual certificates to allow senders and receivers to identify and authorize the communication;
• Support the exchange of messages using the HTTP Request-Response paradigm; and,
• Maintain the agreed behaviour for the exchange and processing of messages.

Message Transmission

Message Transmission in case an HCP’s connection receives a timeout or the HIC is offline:

• If HCP connection times-out/ disconnects before receiving the response:
  • Poll Request can be used to fetch the offline responses available in nphies.
  • Poll Request can’t be used with Eligibility or Status Check use cases as this response must be real time while the connection is opened. In this case, HCP is expected to send another Eligibility Request or Status Check to the HIC.
  • If the HCP sends the same exact request again. nphies SHALL return the response received from the HIC matching the sent request. If the HCP sends a transaction and does not receive any response back, they SHALL send exactly the same transaction again, so he can get the answer which may have arrived at nphies while the provider was reconnecting to nphies.
  • If the HCP sends a Poll request, nphies SHALL return the valid responses based on the criteria sent in the Poll Request (Period, Transactions to be included … etc.)
• If HIC is offline:
  • nphies SHALL send a response message to the HCP indicating the successful receipt of the message and including whether that transaction is queued or the returning the error code in case the payer is offline.
  • nphies queues the messages to be sent to the HIC as soon as its back online, where queuing is applicable.
  • HIC can then send the needed offline response in which case the HCP can pick up the response using the Poll Message.

Duplicate Checking

Upon the receipt of a message, the receiving system SHALL check whether the transaction has been previously received. And if so, then the receiver SHALL send a response to the sender and in the case of nphies does not send the message on to the intended recipient. The type of the response sent by the receiver, or nphies, depends on whether the nphies system already has a response stored from either the internal message validation system or the payer-intended recipient.

Detect and Manage Duplicates

Each transaction has a unique identifier on the main resource in the transaction. For example, the main or focal resource for prior authorizations and claims is the Claim resource and each Claim.identifier is required to be a unique combination of the Claim.identifier.system and the Claim.identifier.value which are both provided by the provider.

If the receiver receives a message which is an exact duplicate of a previously sent message excluding the Bundle.id, that is, the message contains the same MessageHeader.id, focal resource identifier and exact copy of the body of the message, then the message is considered a duplicate.

Type of response returned:,

• If the new message is not a duplicate and has a new identifier not previously sent, then the message proceeds to validation and if is valid it is sent, or queued, to the payer or nphies for processing.
• If the new message has a duplicate identifier and the receiver already has a response from either the internal system or the payer, then the receiver SHALL return the most recent response.
• If the receiver receives a duplicate identifier and does not have a response on file, then the receiver SHALL return a response message indicating that the request message has been ‘queued’ for processing.

Message Transport

All participants in the exchange of messages following this guide SHALL obtain an X.509 Public Key Encryption (PKI) certificate from nphies, and renew or replace that certificate upon expiration, and all message exchanges SHALL use mutually authentication HTTPS message exchange to the nphies endpoint.

Security

All parties SHALL safeguard the contents of messages exchanged when those messages contain Personal Identifiable Information (PII) and/or Personal Health Information (PHI). Parties SHALL also protect and secure their X.509 Certificate(s) and if a breach is suspected then to immediately report the breach and obtain and use a replacement X.509 certificate.

Store and Forward - Queue Management

The nphies clearinghouse SHALL provide store and forward of messages for both HCPs and HICs to minimize the transmission management load on message senders and to support codintions where the message receiver is not directly available when a message intended for them is received by the nphies system. Not all messages are subject to store and forward. Real-time only messages such as Polling, Eligibility Check and Status Check SHALL not be stored if the responder is not currently online and an error indicating such SHALL be returned to the sender.

The nphies queue is provided for messages from and for both providers and insurers to instantiate a loosely-coupled exchange environment where senders need only confirm that they have delivered a message to nphies which SHALL then take responsibility for holding and delivering the message to the intended recipient.

• Provider: Given that all exchanges with HCP systems are provider-initiated, provider systems use Polling to retrieve queued messages. Systems should be programmed to check for queued messages daily and to support automated periodic checks or allow for user-initiated checking during the day which is needed for retrieving responses to prior authorizations for urgent care. The nphies system SHALL add queued-message tags to response messages to indicate that there are currently messages in the queue which may be retrieved via polling at a time to be determined by the provider. Validation failures and payer timeouts would lead to nphies short-circuiting and sending responses to HCPs on behalf of the HIC and identifying nphies as the author of the response. The nphies generated response may identify errors in the message received or may indicate that the message has been queued for delivery to the HIC.
• Insurers: The messages SHALL be supplied on a first-in first-out basis and SHALL be removed from the nphies queue if transmitted to the requester and no transmission error being detected by nphies and the receipt of response from the insurer to confirm the receipt of each queued transaction. nphies SHALL push messages to Payer systems as soon as a message comes into the queue to be transferred to them. Once the HIC system is available, nphies SHALL push all the pended messages one by one to the HIC system. HICs SHALL review the requests and then send the responses to nphies which SHALL queue the responses for intended provider.