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 cycle specific FHIR bundles of type "collection".
Every bundle must mandatorily contain at least one cycle-specific resource while also allowing additional resources that may be referenced from the main cycle specific resource.
For example, the data packet for a coverage eligibility check request will be a bundle of type “HCX CoverageEligibility Request Bundle” and the bundle must have at least one “CoverageEligibilityRequest” FHIR resource embedded in it.
type = “collection”
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:
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 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.
Resource
Description
HCX Coverage Eligibility Request Bundle
CoverageEligibilityRequest
The bundle must contain a CoverageEligibilityRequest resource.
Patient
The document should contain a Patient resource with minimal required information about the patient:
Patient resources should mandatorily have an NDHM identifier.
Patient resources can also have a hospital Id (Medical record number).
Patient resources can also have an insurance id (PMJAY ID).
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
HCX Coverage Eligibility Response Bundle
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.
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
HCX Claim Request Bundle
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
HCX Claim Response Bundle
ClaimResponse
The document must contain a ClaimResponse resource.
Domain Headers:
Key
Description
Payment Notice
Resource
Description
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
This object covers the following aspects of an insurance plan:
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.
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 "HCX Communication 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.
HCX Communication Bundle
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
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
Following sub-section provides details of the attachment handling on the sender and the recipient on HCX.
Last updated
Was this helpful?