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 Structure

nphies is a centralized network and processing system, which will connect all stakeholders to efficiently and effectively manage and monitor the standards-based information exchanges between providers (Hospitals, Clinics, Pharmacies, Optical shops [collectively referred as HCPs]) and payers (Health Insurance Companies (HICs) and TPAs) for the benefit of all stakeholders including the beneficiary.

Actors

Information Exchange Requirements

Units of Information

The basic content model in FHIR is the resource, a topic-specific collection of data elements, e.g., a Patient, Organization, Encounter, or Claim, which contains the data elements to support that topic and refers to other Resources to provide the information elements for that topic. Complex information exchanges such as all the information to document an Encounter is modeled as an Encounter resource which provides certain information on the encounter and refers to the appropriate Patient, Practitioner and Observation, etc. resources.

Information Exchange Packages

HL7 FHIR supports a variety of exchange patterns including point-to-point FHIR RESTful (CRUD) exchange of individual resources; FHIR Operations with defined input and output parameters; exchanges of groups (Bundles) of resources to Message, Document, and other operational endpoints; and the exchange of single resources or resource Bundles over any non-FHIR specified transports such as FTP, SMTP (email), WSI web services, etc.

The business exchanges needed to support eClaim in Saudi have a few defining characteristics which guide the selection of content packaging and content exchange in FHIR:

• The exchanges are made via a central gateway, rather than point-to-point, with the gateway responsible for both validation and routing;
• Communicating parties are separate organizations, from each other and the central gateway;
• Communicating parties are at a material distance such that latency and connection costs are a business consideration;
• The exchanges are typically complex, comprised of multiple resources where the time/version context of the resources is material;
• Each party may be required to have their local information repository; and,
• Each party may engage one or more other companies to do some or all of their processing on their behalf.

This leads to one general packaging guidance, that all needed resources to support the intended information exchange should be included in the same package except where references are made to commonly accessible repositories such as may exist for images, labs, and medications. Given the design of the nphies ecosystem and financial information exchange requirements, nphies is implementing FHIR Messaging as a combination of synchronous and asynchronous exchange of FHIR Message Bundles each containing one, or more when permitted, suite of HL7 FHIR Resources which constitute a coherent information exchange such as an eligibility request or claim.

The message bundle is exchanged via the $process-message operation endpoint of the gateway.

Endpoint Operation: Process Message

All the mentioned use cases in this guide SHALL refer to one endpoint operation e.g. https://hsb.nphies.sa/$process-message or such $process-message endpoint provided by testing and production sites.

Note: conformance testing environments, and general testing environments and their related pseudo-payer conformance applications are set up and designed for technical development and testing purposes. Therefore, implementers SHALL refrain from transacting or sharing any real patient or confidential information through them. Ensure that all Person Identifying Information (PII) and Personal Health Information (PHI) data is masked and dummy information is utilized when executing any testing scenario.

The process message operation accepts a message, processes it according to the definition of the event in the message header, and returns one or more types of response messages.

Process Message Structure will have in-parameters (Input) and out-parameters (Output).

Information Flow

Information exchanges will be satisfied with a combination of real-time synchronous request-response and asynchronous FHIR messaging of information models such as eligibility request and response, claim status check and response, and polling for outstanding responses and return of the response.

The diagram below depicts the typical exchange through the central gateway for exchanges with payers and assumes loose coupling of the gateway front-end (provider side) and back-end (payer side) processes. See the Message Exchange section for greater detail on the steps and actions expected at each step.

Real-Time and Deferred Processing

Real time business processing means that the completed business response to a request is provided as the response to the request, for example the adjudicated response to a claim or authorization request, and deferred business processing means that the completed business response will be provided at a later time and the response to the request will be to acknowledge receipt of the request or provide a validation level response only. While all point-to-point exchanges are real time and the overall exchange design supports real-time end-to-end exchange of business-level message, some use cases are defined to be real time only, others are deferred only and other use cases can support both real time and deferred business processing. A notice indicates that there is no direct business response expected, although an acknowledgement from the immediate receiver is expected, as the notice is the business response and/or a statement of request where the business response, if any, is expected later or out of band. The Use Cases addressed by this guide and the type of business processing is shown below:

FHIR Bundle Resource Hierarchical Structure

The hierarchical representation of the sample structure of FHIR Bundle Resource is shown as below:

Message Events and Transactions

Event Codes and Descriptions

The list below of codes will be used as the .eventCoding in the MessageHeader of the respective transactions. Selecting the link on the event codes below leads to the event message structure in one of the Use Cases where the message is used.

Transactions, Focal Resource and Message Event

The message event codes, presented below, are from the KSA Message Events CodeSystem.

Transactions using the Task Resource

The table below lists the transactions which use the Task resource to accomplish a processing behavior and the Task.code value which indicates the type of activity requested.

Extensions

Extensions are the FHIR technique for including custom yet standardized additional data elements into a data structure, or even a data element, to provide additional information not otherwise defined in the base FHIR data standard. The guide will use some extensions already defined in the FHIR R4 specification and also defines some new extensions just for the purpose of this guide.

Meta Tags

Tags, or coded values, MAY be inserted in the MessageHeader.meta.tag array of response messages sent from nphies to Providers to provide processing advise:

Meta Tag: queued-messages

Although a polling check is a relatively light transaction, the load can become considerable if many providers are checking at a high frequency. While a formal subscription-publication model could be instituted the methods proposed below are lighter, require less maintenance and have been found to provide the same or similar results depending upon the types of providers:

• Message Tagging - a tag may be added by the gateway to provider-bound response messaging to indicate that there are queued messages waiting. For example:

  { 
    "resource":{
  "resourceType": "MessageHeader",
  "id": 123, 
  "meta": {
    "lastUpdated": "2020-12-13",
    "profile": [...],
    "tag": [{
      "system": "http://nphies.sa/terminology/CodeSystem/meta-tags",
      "code": "queued-messages"
    }]
  }
    ...
  }
  

Meta Tag: nphies-generated

While the response to a request sent to an intended recipient will normally come from that recipient, periodically nphies will be required to generate an interim response on their behalf. In those circumstances the response will have a ‘nphies-generated’ tag in the MessageHeader. For example:

{ 
  "resource":{
    "resourceType": "MessageHeader",
    "id": 123, 
    "meta": {
      "lastUpdated": "2025-01-13",
      "profile": [...],
      "tag": [{
        "system": "http://nphies.sa/terminology/CodeSystem/meta-tags",
        "code": "nphies-generated"
      }]
    }
  ...
}