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.


Announcement

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: "https://www.abchealth.com/policy/ABCGoldHealthPolicy.html"
  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:

Coverage:
  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.

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

Prc(Cataract):
  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:

Exclusions:
  Dgn(Ebola)
  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:

Conditions:
  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.

Standards for Health Insurance Policies (SHIP)

1. Introduction

Imagine a world where contracts and agreements between parties could get settled by a system of computers in microseconds! 

  • The interpretation of the agreements would be standard: the same pre-conditions would result in the exact same outcome. 
  • The speed of settling agreements or disputes would be less than a second, not hours, or days, or months, or years. 
  • Outcomes of settlements or disputes would follow the rules / guidelines laid out in the agreements, with better accuracy
  • The possibility of influencing the clearing house, or the contract settlement party to act with bias would vanish. Further, there would not be any conflicts of interest.
  • The speed of human endeavour would increase by orders of magnitude: it would not be limited by the rate determining step of slow contract settlements / enforcements. 

That is the promise of smart contracts, in other words, a way for contracts to get settled by computers. While a lot of work has gone into the field of smart contracts, Vitraya chose to implement smart contracts in the field of health insurance settlements. 

Health Insurance settlement systems in most parts of the world are ridden with a number of challenges: slowness, low accuracy, massive cost. The WHO estimates that the cost of health insurance administration is ~10% of global healthcare spending. That would peg the cost of the Health Insurance settlement system at $800 Billion. That is more than the annual defence spending of the G8, and also more than the GDP of Vietnam!

The goal of automating health insurance contract settlement must begin with creating standards for health insurance policy contracts. Insurance policy clauses are a free for all, and with seemingly infinite degrees of freedom: one particular policy mentioned the term “reasonable costs” eight times, and the word “etc.” ten times, without defining what reasonable or etc. means. While it may or may not not be intended, what reasonable really means is “at the pleasure of the insurer”. Another policy calls itself a “comprehensive policy, but defines that the term comprehensive does not cover any damage caused by water or flooding. 

2. Why is a standard necessary

In creating standards for a health insurance policy contract, we restrict the degrees of freedom that policy designers can exercise. The objective of restricting the degrees of freedom is to enable predictability of contracts, thus doing away with vagueness, confusion, and subjectivity. 

Once a set of standards have been defined, it is possible to create mathematical algorithms that can apply the rules and clauses covered in the policy to an insurance settlement. This, along with the standard diagnostic reports, standard medical procedures, and standard bill formats will enable computers to take over the job of adjudicating and interpreting insurance claims. 

By creating this standard, Vitraya aims to – 

  1. Create a framework for the degrees of freedom that policy designers can exercise in defining new policies
  2. Standardize insurance policies and ensure policy clauses are consumer friendly
  3. Create an auto-adjudication / settlement system that will 
    • Enable health insurance settlements real-time
    • Create predictability of insurance settlements, thus benefiting the insurer / payer, the hospital / provider, and the patient
    • Create automated frameworks and processes through which the counterparties in health insurance can negotiate with each other and agree on the rules of the settlement. The counterparties of health insurance are insurer/ payer, hospitals/provider, patient, regulators. 

3. Digital standards in insurance 

There have been some attempts at creating an electronically settle-able standards for insurance contracts. The ACORD standard is one such attempt. However, substantive efforts for creating such a standard for health insurance has not emerged yet. The FHIR standard and Medical Markup Language (MML) are some attempts to create standards for healthcare, but they do not extend to enabling insurance settlements. 

It is in this context that Vitraya took on the task of creating a digital Standard for Health Insurance Policies (SHIP). This is also against the backdrop of a call for innovation towards creating a clearance and settlement system by the National Health Authority (NHA) of India and the Insurance Regulatory Development Authority of India (IRDAI). SHIP is the first piece of creating a smart contracting system for health insurance. One of the SHIP standards is a markup language that the NHA refers to as the Policy Markup Language, or more specifically the Health Insurance Policy Markup Language (HIPML).

Our work therefore, is the first publicly available, open source standard for health insurance anywhere in the world. It is a basic framework and can be extended/modified by insurers/developers to suit the policy and industry contexts specific to their region. 

In the coming weeks and months, we will be making a number of releases. These releases will include – 

  • enhanced version of HIPML
  • tools to convert policies from English to HIPML and HIPML to English
  • tools for software developers to write and read health insurance policies in HIPML

4. Why are we making the SHIP and HIPML standards open source?

We believe that making the standards open source will accelerate the adoption of digital contracts and automated adjudication in health insurance. We believe that this will also serve to create a real use smart contracts in action. 

Link to context about SHIP and HIPML

Link to HIPML specification