To assist implementers in the ecosystem to create flow specific payload defined in FHIR spec applicable in HCX, an implementation guide (IG) defining a set of rules about how FHIR resources are used (or should be used), with associated documentation to support and clarify the usage will be created.

Such a publication can be used to validate content against the implementation guide as a whole.

The extended profiles and structures of the FHIR bundles and resources to be used in HCX are available here.

The domain data model consists of the electronic claim (e-claim) objects (a.k.a. eObjects) that are designed to capture the required information essential for processing a health claim transaction. The e-claim objects, being machine -eadable, facilitate the flow of data exchange between different systems and data processing in health claim transactions without the need for human intervention.

Guidelines for eObjects

Bundle Structure

• All e-claim objects will be modelled as FHIR bundles of type "document", with "bundle.composition.type" specifying the type of bundle.

• The first resource in the bundle shall be a “Composition” resource followed by a series of other resources referenced from the “Composition” resource. The elements “type”, “category” and “section” in the “Composition” shall be used to define the purpose and set the context of the document.

• For example, the data packet for a coverage eligibility check request will be a bundle with “bundle.composition.type” as “Coverage Eligibility Check” and the bundle will have a “CoverageEligibilityRequest” FHIR resource embedded in it.

Identifiers:

• For any resources requiring identifiers (e.g. Patient.identifier), naming systems have to be defined and agreed upon within the affinity domain to be specified in the “identifier.system” element to namespace the identifier value. This can allow an entity or resource to be referenced against system-specific identifiers. For example, a patient may be referenced as:

• For some identifiers, “identifier.type” can be used to provide additional information.

• “identifier.use” can be used to indicate what/where/how a particular identifier might be used for.

• Example:

Resources

• For external entities like patients, organisations, practitioners, etc, a reference alone is enough unless additional information is required to be passed. For example, patient address & other demographics.

Domain Header

• All eObjects shall be encrypted and sent in the API request body and cannot be accessed by the HCX gateways. However, there is a provision in the API request body for providers and payers to share certain eObjects' related information with the HCX gateway. This information can be sent in the domain_header part of the request body (as key-value pairs) which can be accessed and stored by HCX gateways for auditing and reporting purposes. Each eObject shall define the domain header values that are to be sent in the API request body.

Search Parameters

• In addition to the workflow APIs for claim processing workflows, HCX also defines APIs for searching eObjects. To support the search APIs, all eObjects will define the search request parameters.

Questions for Consultation

Question 1

Payors/Providers can share certain information about eObjects with the HCX gateways as part of in the request body. At present, domain working groups have kept these headers empty. Please suggest the data in each eObject that can be shared with the HCX gateways.

Question 2

HCX defines search APIs to search eObjects. The search parameters for each eObject are not currently defined. Please suggest the search parameters for each eObject. Also, should there be additional search APIs that do not require FHIR encoding of the response payload? Kindly elaborate on the nature of these APIs.

Question 3

Proposed domain data models and terminologies require adopting FHIR as domain object standards. How does one facilitate and enable the participants to adopt FHIR and change their systems and processes?

This version of the HCX specification defines the domain model specifications required for the following eObjects:

• Coverage Eligibility Request and Coverage Eligibility Response

• Claim Request and Claim Response: These objects will be used for both Pre-Authorization and Claim use cases (and for Pre-Determination also in future).

• Payment Notice and Payment Reconciliation

As mentioned in the design considerations for domain specification, the eObjects leverage HL7/FHIR4 specification and extend it, wherever required.

Coverage Eligibility Request

As per the design considerations and guidelines listed in the previous sections, the coverage eligibility request payload has to be created as an FHIR document bundle. The bundle should have the following resources:

Domain Headers:

Search Parameters:

Coverage Eligibility Response

Domain Headers:

Search Parameters:

Claim Request

Claim object is used by providers to submit pre-authorization and claim requests to the payers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “claim.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization requests and as “claim” for Claim requests.

Domain Headers:

Search Parameters:

Claim Response

ClaimResponse object is used by payers to send the response for pre-authorization and claim requests to the providers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “ClaimResponse.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization responses and as “claim” for Claim responses.

Domain Headers:

Search Parameters:

Payment Notice

Domain Headers:

Search Parameters: