The most significant aspect of domain specification would be agreement on formats for data exchange and terminologies (taxonomies) being used in those data models. These would mainly include:
Domain data model - Schema definition of domain entities like Claims, Providers, Payors, Policies, etc. Please note that based on available DSLs some of these data models may be flexible, e.g. policy schema if Policy Markup Language (PML) is available.
Metadata specifications - Metadata is data about data, data associated with an object, a document, or a dataset for purposes of description, administration, technical functionality, and preservation. For the context of claims, this would mainly involve coding systems and suggested values for key claim attributes like disease codes, procedure codes, diagnostic codes, billing-related codes (e.g. room rent, ICU charges, etc.), etc.
Domain Specific Language(s) - Usually known as DSL, these may be developed When the attributes of the entity are variable from use case to use case but need to adhere to some common constraints/characteristics like types of data element it can contain, the relationship between two data elements, number of occurrences of data elements, etc. Examples of such entities within a claims data exchange would be policies, bills, contracts. In such cases, defining a markup language (DSL) rather than the entity itself allows needed flexibility to the ecosystem to innovate on such entities. These can be thought of like HTML, where multiple flavours of web pages can be defined using the markup elements.
In order to achieve this, in line with the key design principles detailed in Health Claims Data Exchange - Open Specifications, following key design guidelines are proposed:
Data specifications should be broken down to simpler fundamental units as far as possible.
In order to leverage existing knowledge and resources and provide wider interoperability, data specifications should extend/ reuse/ adopt international/ national models wherever available/applicable. In order to follow this in claims context, data specification should leverage resources as follows:
Leverage HL7/FHIR R4 specifications wherever possible
Leverage NRCES FHIR specifications where base FHIR specs need contextualization to the Indian context
Create minimal extensions needed in case both base FHIR and NRCES specs are not enough to support the use case
FHIR Document profiles appropriate for the protocol should be created composed of base FHIR resources
Data specifications should be created with the principle of minimalism and inclusivity. In order to achieve this:
Specs should permissive cardinalities as much as possible. E.g. they should require minimal mandatory fields to enable maximal inclusion. As a thumb rule, wherever unsure of the cardinality of an attribute, the most permissible one should be used.
Specs should use permissive terminologies/code binding strength as much as possible. E.g. in the FHIR terminology construct (Section 4.1.5), if there’s a conflict in choosing between “extensible” and “preferred” strengths for a coding system, “preferred” should be chosen.
Data specifications should be extensible i.e. they should allow a way to capture extra information that was not initially included during the model design. To achieve this:
It may provide a simple map of key-value pairs. Future versions of the data model may choose to create mandatory/optional names attributes in the data models after researching the wider applicability of such fields.
Data specifications should allow for namespacing in field names to indicate the source/reason/category of the extended fields.
It is recommended that all timestamps be captured in ISO-8601 format e.g. 2020-08-15T17:02:53.495+05:30. APIs may define display format property to indicate the human-readable format most suitable for display.
Based on the priorities listed above and design considerations, key domain specifications included in Phase 1 are detailed in the following sub-sections.
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.
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
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:
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.
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 also defines APIs for searching eObjects. To support the search APIs, all eObjects will define the search request parameters.
Payors/Providers can share certain information about eObjects with the HCX gateways as part of domain headers 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.
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.
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?
Instructions to send responses to the consultation questions are available here.
There are two key DSLs being considered for the Health Claims Exchange - Policy Markup Language (PML) and Bill Markup Language (BML). These are currently work in progress and are expected to be released in the later version of HCX specifications after substantial proof of concept development with various members of domain working groups.
The purpose of policy markup language is to provide a DSL to payers such that the policies can be encoded in machine readable format, thereby helping with the automation of eligibility check and adjudication processes.
The purpose of bill markup language is to provide a DSL to payers such that the supporting bills can be parsed as machine readable structured data, thereby helping with the automation of adjudication processes.
The section above refers to adopting appropriate DSLs for policy and bills. Kindly suggest your views on the useability of such domain-specific language and provide prior examples.
Are there any existing solutions that have been used/experimented with? Please provide examples.
Instructions to send responses to the consultation questions are available here.
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.
To achieve semantic interoperability, it is recommended that HCX data standards incorporate well established and suitable terminology and coding systems.
In various HL7 standards (including FHIR), these are expressed as Concepts and codes and forms essential vocabulary, ontological binding for resources used to describe document types/categories, element codes and clinical coding like procedure codes, diagnosis codes etc. The data standards defined using FHIR resources and types usually will require agreement on references and usages, through agreed Code Systems and codes, typically manifested through ValueSets.
For Clinical resources (e.g. Condition, Procedure, Observations) - please refer to the guidance issued by NRCeS.
In India, SNOMED-CT is free for use by all as Clinical Terminology, while ICD codes are used for classifications.
Labs typically use LOINC codes
For other code/concepts in the FHIR based data standards, we would recommend guidelines
If any attributes are marked as “required” - then, use of the codes defined in the value sets
If it is marked as “preferred” or “extensible” - then, users are encouraged to draw from the specified codes for interoperability purposes, unless deemed appropriate within the affinity domain.
If marked as “example” - then the domain must agree and define a value set for usage.
ValueSet may be created derived from existing sets, either composed/included from the base or expanded.
For insurance claim domain specific element attributes (e.g. Claim.type) - the domain may define and establish value sets, as suitable in India’s context.
For the broader NDHM interoperability and conformance, HCX would align/inherit domain specific guidelines.
The table below lists the code systems/value sets proposed by current domain working groups. Based on the above guidelines, we are proposing them to be “preferred” or “example” binding strengths as per FHIR Terminology binding strength definitions (Section 4.1.5).
HCX or a neutral protocol supporting organisation will host domain specific FHIR Terminology Services which the ecosystem can leverage to retrieve information and use, and validate resources as defined by the IG.
During multiple discussions with the ecosystem, it has been suggested that while the specifications suggest recommended terminologies, they are not yet mandated (hence the low binding strength's against each terminology). Kindly provide your view on mandatory standardisation of terminologies and approaches to enable your suggestions.
In your view, what clinical terminologies and codes (e.g SNOMED-CT, ICD-10, LOINC) be considered? In addition, are you aware of any well established and accepted codes/value sets available that can be applicable to the Indian scenario? Kindly provide details.
Instructions to send responses to the consultation questions are available here.
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.
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:
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.
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.
Terminology name
FHIR Value Set link
Proposed Binding Strength
Insurance Company Owners
(coverageeligibilityrequest.insurer)
Preferred
Procedure Type
(claim.procedure.type)
Example
Procedure Code
(claim.procedure.procedureCode)
Example
Denial Codes (claimresponse.item.adjudication.reason)
Preferred
Procedure Modifiers
(claim.item.modifier)
TODO
Example
Service Categories
(claim.item.category)
Example
Service Codes
(claim.item.productOrService)
TODO
Preferred
Medical Speciality Type
(practitionerRole.speciality)
Preferred
Health Service Provider role
(claim.careTeam.role)
Example
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.
structure definition: CoverageEligibilityRequest Document
CoverageEligibilityRequest
The document must contain a CoverageEligibilityRequest resource.
FHIR Profile: link
structure definition: CoverageEligibilityRequest
Patient
The document should contain a Patient resource with minimal required information about the patient (refer to rows #38-42 in the “Coverage eligibility check” sheet).
FHIR Profile details:
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.
structure definition: Patient
Coverage
The document should contain one or more Coverage resources with minimal information of the policy about which the information is requested (refer to row#30 in the “Coverage eligibility check” sheet).
FHIR Profile details:
Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.
structure definition: Coverage
Key
Description
Key
Description
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.
structure definition: CoverageEligibilityResponse Document
CoverageEligibilityResponse
The document must contain a CoverageEligibilityResponse resource.
FHIR Profile: link
structure definition: CoverageEligibilityResponse
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.
structure definition: Coverage
Key
Description
Key
Description
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.
structure definition: ClaimRequest Document
Claim
Coverage
The document should contain one or more Coverage resources with minimal information on 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.
structure definition: Coverage
Encounter
Condition
Signature resources
List of signatures by Hospital, Doctor and Patient associated with this Claim request.
structure definition: Signature
Key
Description
usage
“preauthorization” or “claim”, to indicate the use case this eObject is being used for.
Key
Description
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.
structure definition: ClaimResponse Document
ClaimResponse
The document must contain a ClaimResponse resource.
FHIR Profile: link
structure definition: ClaimResponse
Key
Description
usage
“preauthorization” or “claim”, to indicate the use case this eObject is being used for.
Key
Description
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.
FHIR Profile: link
structure definition: PaymentNotice
PaymentReconciliation
The document should contain a PaymentReconciliation resource with information about the payment related to this payment notice.
FHIR Profile: link
structure definition: PaymentReconciliation
Key
Description
Key
Description