How can a Digitized Health Policy help improve Claim Settlements?

Health Claim Settlement process today is highly manual and needs manual checks from various industry participants. This results in delays in processing of claims, errors and omissions. One part of the checks are related to establishing the authenticity of the claim – checking the validity of the policy, verifying documents, judging the medical necessity for the procedure / treatment. The other and an important part is the application of rules, terms and conditions that are laid out in the Health Insurance Policy.

Simply put, the basic verification that is needed to authorize or settle a claim is applying the rules that are provided in the Policy in an unambiguous and consistent manner. This can be achieved if the Policy’s rules are digitized and are readable by a software application. In the context of claims settlement, a Claims adjudication software needs access to a service that immediately runs the data related to the claim through multiple rules written in the policy and immediately gives 

  1. Its assessment on the admissibility of the claim, and
  2. The limit of amount that can be covered for the particular case

How complex are Health Insurance Policies?

At a high level, Insurers define multiple products for Individuals and families. Individual Policy, Family Floater Policy are terms you would have heard if you have purchased Health Insurance Policies.

The complexity goes to the next level for Corporate Policies. Corporates negotiate terms and conditions and pricing with the Health Insurance Companies and offer Health Insurance as benefits to their employees. These Corporate Policies increase the complexity in terms of varieties of exclusions, waiting periods, varying degrees of coverage to the families of the employees, varying coverages / limits to the employees on the basis of their designation, tenure etc.

Some examples

Consider some example Policy rules below:

  1. Policy A, which is an individual policy excludes Plastic surgery unless the surgery is required for medical reasons / accident.
  2. Policy B which is a Corporate Policy provides maternity cover for the employees but limits the amount to Rs 70,000. However, any complications during maternity are covered upto the Sum Insured.
  3. Policy C which is a Corporate Policy covers upto Rs 7 Lakhs, but in case of a new employee (first year of employment), the parents of the employee have coverage only upto Rs 2 lakhs.

The above are just a few examples which help us establish the need for a digitized policy which can be accessed during Claims process. Also, having a language gives the Insurers the flexibility to keep evolving these rules as per Business needs with a guarantee that the Claims follow the rules specified seamlessly.

Health claims in an ideal Healthcare ecosystem

An ideal Healthcare ecosystem would integrate the whole journey of the patient / policyholder and ensure transparency and consistency in the claims settlement. Key ingredients to the transparency and consistency are the objective definition of policy rules, terms & conditions and objective application of these rules in real-time.

First version of HIPML v0.1.0

TL;DR: We are releasing the first version of a policy markup language that could be used to write/digitize polices. Review it and give feedback and suggestions. We have also built an application on top of this standard. Play with it to understand how HIPML could be put into action. If you like these efforts, please share! We believe digital transformation in healthcare sector could only happen through the participation of the community, not in silos.


In our previous blog, we have written about the necessity of standards in Healthcare Insurance industry (SHIP and HIPML). Today, we are excited to announce our first version of HIPML version 0.1.0 along with an application built on top of HIPML for creating health insurance policies (hereon referred to as policies).

HIPML v0.1.0 Introduction

HIPML(hereon referred to as PML) is a language designed to write policies in a human and machine friendly manner. To understand the background on HIPML, please read our previous blog.

One of the major goals for the PML is to make it small in terms of vocabulary and grammar, so that one could memorize the whole language with little effort and not refer to the specification repeatedly while writing policies. The language semantics are chosen with this in mind. Instead of going through the building blocks of PML in detail(which you could find here), let us jump right into policy creation using PML.

A health insurance policy usually is composed of the following sections:

  1. Policy Attributes
  2. Coverage
  3. Exclusions
  4. Conditions
  5. Definitions and Contact

1. Policy Attributes

This is the first section in a policy, usually at the top, and has the attributes of a policy that uniquely identify it. Like, Name, Unique identification number given by IRDAI, Issuer, type of policy, etc.. This is how you describe the policy attributes in PML:

Policy Attributes:
  Name: "ABC Gold Health Policy"
  Issuer: "ABC Insurance Corporation"
  UIN: "ABC123DEF456"
  Type: "Medical"
  Category: "Group"
  URL: ""
  Version: "1.0.0"
  Approval Date: 2019-01-01
  Effective Date: 2019-02-01
  Expiration Date: 2024-12-31
  Sum Assured: One of the following:
    - Amt(2,00,000) if Var(Employee Designation) is "Staff"
    - Amt(3,00,000) if Var(Employee Designation) is "Associate"
    - Amt(5,00,000) if Var(Employee Designation) is "Director"
    - Amt(1,00,000) default
  Copay %: 10

The section starts with the name of a section, a semi-colon followed by attributes in the format Attribute name: Attribute value. Straight forward.

You would notice that Sum Assured is not a fixed value, but a selection from a set of values depending on associated conditions. This is usually the case of with Corporate group policies. Here, the keyword Amt indicates that the value is amount/monetary value and Var indicates a variable to the policy. Variables of policies are Poicy start date, Sum Assured, Hospitalization date, etc… If none of the conditions match, then a “default” value will be chosen as “Sum Assured”.

Let us move on to a more important section…

2. Coverage

The coverage section lists out the covered procedures, hospital services and sometimes diagnoses, along with any conditions against them. Let us see how we could write Coverage section in PML:

  Prc(Coronary artery bypass surgery)

The example above says that the policy is covering the listed procedure(Prc stands for medical procedures) is covered. Of course, this is a very simple case(but not uncommon), where a procedure is covered with no strings attached. Let us look at an example where there is a limit on the coverage amount.

Note: the list of procedures would be standardized based on ICD-10 PCS standard with some additions.

  Prc(Minimally invasive CABG):
  	Limit per claim: Amt(2,00,000)

The above example is probably self-explanatory. It just mentions the maximum amount that can be paid agains the stated procedure in a single claim. These limits could be set per claim, per person, per policy period, per year and a few others. Let us look at another example:

  Limit per claim:
    One of the following:
      - Amt(50,000) if Var(Employee Designation) is "Director"
      - Amt(40,000) if Var(Employee Designation) is "Asociate" and Var(Enhancement Type) is "100%"
      - Amt(35,000) if all of the following are true:
        - Var(Employee Designation) is "Staff"
        - Var(Policy Enhancement Type) is "50%"
		- Var(Relation to the Subscriber) is "Self"
      - 5 % of Var(Sum Assured) default

Here the claim amount limit is not a fixed value. It could one among many. In such cases, we could write One of the following: followed by some amount and condition combinations as shown above. In the above example, if the Employee Designation is “Director” then the amount would be 50,000; if it is “Associate” and if the Policy Enhancement Type is “100%”, then the limit is 40,000, and so on. The third condition uses a phrase all of the follwing are true:. This means if all of the statements that follows are true, then the amount will be 35,000. And, in case, none of the conditions are satisfied, then the limit is 5% of Sum Assured. This is known as the default value.

As shown above, we can represent complex policy conditions in PML. Let us look at an example where the coverage for a particular procedure depends on some condition.

Dgn(Kidney diseases):
  Limit per policy year: Amt(1,00,000)
  Included only if:
    number of months between Var(Policy start date) and Var(Admission date) is greater than 36
    and Var(Pre-existing conditions) does not contain Dgn(Diabetes)

Again, the condition stated after the phrase Included only if: has to be true for the coverage item to be included. The Dgn here means Diagnosis. The phrases number of months between [DATE1] and [DATE2] and does not contain are very literal in their meaning.

3. Exclusions

This section lists all the procedures, diagnoses and hospital services that are excluded in the policy. In some cases, these exclusions may have exceptions (there by making them inclusions). Example:

  Svc(Room rent for attendants)
  Prc(Minimally invasive CABG):
    Excluded unless: Var(Sum Assured) is greater than or equal to Amt(5,00,000)

The last exclusion item above has an exception, written as Excluded unless: followed by a condition.

4. Conditions

This sections varies between policies, but there are usually two important things they talk about. Conditions that determines the eligibility of a patient and those that determines the admissibility of a health claim for authorization and adjudication. Patient Eligibility and Claim Admissibility are what we will cover in PML. This section usually includes the procedure for submitting claims and the process for legal disputes. Example:

  Patient Eligibility:
    Number of days between Var(Policy Expiration Date) and Var(Hospitalization Start Date) >= 0
    and (any one of the following is true:
      - Var(Patient relationship with subscriber) is "Child" and Var(Patient Age) is less than 25
      - (Var(Patient relationship with subscriber) is "Self" and Var(Patient Age) is less than 65)
      - Var(Plan type) is "ABC Platinum Plan")
    and Var(Patient Nationality) is "Indian"
  Claim Admissibility:
    Number of days between Var(Policy Start Date) and Var(Claim Submission Date) >= 0
    and number of days between Var(Hospitalization Start Date) and Var(Claim Submission Date) is less than 15
    and Var(Country of treatment) is "India"

The Patient Eligibility and Claim Admissibility are determined by an arbitrary number and combination of conditions which eventually evaluates to true or false.

The last two sections DEFINITIONS and CONTACT may not have much relevance in coverage determination as of now. But, you can still mention them and they will be interpreted as is.

That’s it. We have just covered most of the aspects of PML. As mentioned earlier, it is meant to be simple, concise and intuitive, but powerful enough to describe the complex conditions that are present in health insurance policies. We have analyzed multiple policy documents and almost all the coverage conditions and patient eligibility conditions could be expressed with this version of PML. But, we are sure that there will be many cases the current version may not support. That’s where we need help from the community. Your feedback and suggestions would be greatly helpful. You could also contribute directly to the specification on GitHub.

Specification and some hypothetical examples are fine, but it will be more interesting and fun if we can play with the language and write policies with complex rules. For that, we have built a web application that allows users to create policies in PML and test them. Building this application validated (and invalidated) a lot of our initial assumptions.

Play with the application to get a sense of how PML could be put in practice. It loads a default policy in PML format for a quick start.

There are multiple things we can do on top of PML. Tools for creation, testing and maintenance of polices. Automated claim adjudication systems. Digital contracts that will allow for auto-payments. Rule engines. We could build things we were not able to imagine earlier due to the constraints imposed by hand-written-free-text-open-to-different-interpretations policy documents.

Overall, we are very excited after achieving this milestone in our journey to digitize health insurance policies, which surely would help in transforming how healthcare systems are built. There is a long way to go and we believe we have taken our first step, an important step. We hope to meet a lot of you in this journey as contributors and users.

Thank you for reading.

Do not forget to give your feedback and suggestions, if any; and to share it with others who may want to participate in this effort.

Note to Developers: The HIMPL is a simple language with small vocabulary and limited grammar. You could use any modern programming language to build parsers and applications on top of them. We have chosen ANTLR to build the parser for the web application mentioned above. The ANTLR grammar file is in the Git repo. ANTLR lets you to generate parser code in multiple programming languages. We will also write a tutorial (and share it in the same repo) on how to use ANTLR to build a parser in some popular programming languages. Again, it is not necessary to use ANTLR.