Domain Data Models

Guidelines to create and definition of eObjects used in the current version of the protocol

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-readable, 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.

  • type = “document”

  • composition

    • type = “Coverage Eligibility Check Bundle”

    • section : cardinality (1..1)

      • code = “Coverage Eligibility Request”

      • entry : cardinality (1..1)

        • reference : “CoverageEligibilityRequest”

  • CoverageEligibilityRequest FHIR resource

  • Patient FHIR resource

  • Coverage FHIR resource

  • Any other resources referenced in the CoverageEligibilityRequest resource

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:

{
 "resourceType": "Patient",
 "identifier": [
   {
     "system": "https://ndhm.gov.in/patients",
     "value": "hinapatel@ndhm"
   },
   {
     "system": "https://pmjay.gov.in/beneficiaries",
     "value": "QWRT23456"
   }
 ]
}

  • 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:

{
 "type": { // type of identifier
   "coding": [
     {
       "system": "http://terminology.hl7.org/CodeSystem/v2-0203",
       "code": "EI",
       "display": "Employee Number"
     }
   ]
 },
 "system": "https://esi.karnataka.org/employees", // naming system
 "value": "BEN-ID-1001"
}

Resources

  • For external entities like patients, organisations, practitioners, etc, a reference alone may be 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 shall also define APIs for searching eObjects. To support the search APIs, all eObjects will define the search request parameters.

eObjects

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 Pre-Determination, Pre-Authorization and Claim use cases.

  • Payment Notice and Payment Reconciliation

  • Insurance Plan

  • Communication Request and Communication

  • Task

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:

Resource

Description

Composition

type: should be a code representing Coverage Eligibility Request document type.

section: The document shall have one section with a single entry having reference to CoverageEligibilityRequest resource.

CoverageEligibilityRequest

The document must contain a CoverageEligibilityRequest resource.

Patient

The document should contain a Patient resource with minimal required information about the patient:

  1. Patient resources should mandatorily have an NDHM identifier.

  2. Patient resources can also have a hospital Id (Medical record number).

  3. Patient resources can also have an insurance id (PMJAY ID).

  4. Patient resources can also have employee IDs and other business identifiers.

Coverage

The document should contain one or more Coverage resources with minimal information of the policy about which the information is requested:

  • Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.

Domain Headers:

Key

Description

Coverage Eligibility Response

Resource

Description

Composition

type: should be a code representing Coverage Eligibility Response document type.

section: The document shall have one section with a single entry having reference to CoverageEligibilityResponse resource.

CoverageEligibilityResponse

The document must contain a CoverageEligibilityResponse resource.

Coverage

The document should contain one or more Coverage resources with minimal information of the policy about which the information is being returned.

FHIR Profile details:

  • Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.

The Coverage Eligibility Response should include the Insurance Plan URL as part of the domain header as described below . The URL should point to an Insurance Plan object as defined here.

Domain Headers:

Key

Description

x-hcx-insurance_plan_url

Url to the InsurancePlan object with the details on benefits, required documents and other important information to submit claims

Claim Request

Claim object is used by providers to submit pre-determination, pre-authorization and claim requests to the payers. The same eObject can be used for all 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 "predetermination" for Pre-Determination requests, “preauthorization” for Pre-Authorization requests and as “claim” for Claim requests.

Resource

Description

Composition

type: should be a code representing Claim Request document type.

section: The document shall have one section with multiple entries having references to Claim and Signature resources.

Claim

The document must contain a Claim resource.

Coverage

The document may contain one or more Coverage resources with minimal information on the policy for which the claim is being raised.

FHIR Profile details:

  • Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.

Encounter

Details of the Encounters during which this Claim was created or to which the creation of this Claim is associated.

Condition

Details of the health conditions relevant to this Claim request.

Domain Headers:

Key

Description

Claim Response

ClaimResponse object is used by payers to send the response for pre-determination, pre-authorization and claim requests to the providers. The same eObject can be used for all 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 "predetermination" for Pre-Determination requests, “preauthorization” for Pre-Authorization responses and as “claim” for Claim responses.

Resource

Description

Composition

type: should be a code representing Claim Response document type.

section: The document shall have one section with a single entry having reference to ClaimResponse resource.

ClaimResponse

The document must contain a ClaimResponse resource.

Domain Headers:

Key

Description

Payment Notice

Resource

Description

Composition

type: should be a code representing Payment Notice document type.

section: The document shall have one section with a single entry having reference to PaymentNotice resource.

PaymentNotice

The document must contain a PaymentNotice resource.

PaymentReconciliation

The document should contain a PaymentReconciliation resource with information about the payment related to this payment notice.

Domain Headers:

Key

Description

Insurance Plan

The Insurance Plan object helps in determining the benefits of the plan (not the policy specific to the subscriber which is present in the Coverage object), but more generic information about the plan/product. It also contains the documents required, questionnaires to answer and any important information necessary for a successful preauthorization/claim submission, with an objective to reduce the claim submission errors. It may also help in rendering the claim creation UI on the provider side by allowing to filter/view only the necessary options in stages. More details about it can be found in the Policy Markup Language section.

This object covers the following aspects of an insurance plan:

Resource
Description

InsurancePlan

InsurancePlan basic plan details required for administrative purposes:

  • Most of the basic details like name, IRDA UIN as identifier, validity, etc.. are covered in InsurancePlan profile.

  • InsurancePlan.plan.specificCost is used to describe the individual benefits that are covered under the plan. A benefit could be expressed against a procedure, a package (in the context of Indian Health Insurance industry), a diagnosis, a physical good or a service. For each benefit, the cost and the count upto which the benefit would be reimbursed could be specified.

HCXDiagnosticDocuments

The documents required to submit at predetermination, preauthorization and/or claim stage.

ProofOfIdentityDocuments

The proof of identity requirements prior to the predeteermination, preauthorization and/or claim stage.

ProofOfPresenceDocuments

The proof of presence requirements prior to the predeteermination, preauthorization and/or claim stage.

Questionnaires

The questionnaires required to be answered and submitted along with a predeteermination, preauthorization and/or a claim request.

InformationalMessages

The informational and compliance messages that the provider should be aware of, prior to the predetermination, preauthorization or claim request.

Communication Request

The FHIR resource CommunicationRequest is used by payors to send a communication request to providers requesting additional information about a predetermination, preauthorization or a claim request. In future, this object may be used for other communication purposes also.

Resource
Description

CommunicationRequest

This resource is a record of a request for a communication to be performed. It shall contain the following details:

  • about - reference to the predetermination, preauthorization or claim request for which the communication request is created

  • payload - text, attachments or resources to be communicated to the recipient of the communication request

Communication

The FHIR resource "CommunicationDocument" bundle is used by providers to respond to the communication requests sent to them. Communication is a conveyance of information from one entity, a sender, to another entity, a receiver. The bundle should have the following resources:

Resource
Description

Composition

type: should be a code representing Communication document type.

Communication

The bundle must contain a Communication resource which is a record of a communication even if it is planned or has failed. It shall contain the following details:

  • about - reference to the predetermination, preauthorization or claim request for which the communication is being sent

  • payload - text, attachments or resources to be communicated to the recipient of the communication

Task

The Task object is used for capturing activities that can be performed and for tracking the completion of the activity. In this version of the specification, the Task object is intended to be used for providers to do a status check of requests submitted by them and for the payors to respond with the status details. FHIR also recommends the usage of Task FHIR resource for status requests & responses (link).

Resource
Description

Task

Task object is used as the payload in status request and response APIs. The object shall have the following details:

  • code - specifies the nature of the task, i.e. status check

  • focus - specifies the context identifiers (e.g case-id for a registered pre-auth, claim id of the provider TMS)

  • input - additional information about the context that may be needed in the execution of the task. e.g.: type of entity - preauthorization or claim, etc

  • output - carries the result of a status request. The result is the status code reflecting the status of the corresponding request (CoverageEligibilityCheck, PreAuthorization, Claim, etc..). The valueSets for the status codes must be the same as specified in the corresponding response FHIR profiles

PreviousDomain SpecificationsNextHandling Attachments

Last updated