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:
- Policy Attributes
- 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,
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…
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
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.
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.
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"
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.