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.
- 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.
HCX CoverageEligibilityRequest Bundle
- type = “collection”
- CoverageEligibilityRequest FHIR resource
- Patient FHIR resource
- Coverage FHIR resource
- Any other resources referenced in the CoverageEligibilityRequest resource
- 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": "[email protected]"
},
{
"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"
}
- 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.
- 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.
- 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.
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.
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:
|
Coverage |
Key | Description |
| |
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:
|
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.
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 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 | |
Coverage | |
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. |
Key | Description |
| |
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. |
Key | Description |
| |
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. |
Key | Description |
| |
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:
|
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. |
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:
|
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.
Resource | Description |
|---|---|
HCX Communication Bundle | type: should be a code representing Communication document type. section: The document shall have one section with a single entry having reference to Communication resource.
FHIR Profile: link
structure definition: Communication Bundle |
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:
|
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:
|
Last modified 28d ago