Beginning 41as early as 1997, when the first 430 courts were computerised in India, we now have nearly 15,000 courts in India using computers for tracking cases and hearings. This data is made available on a public website (ecourts.gov.in), so litigants can see details of what happened in the last hearing and when the next step in the process will happen. As systems go, this is possibly one of the largest justice systems to be deployed anywhere in the world. The British court system (on which the Indian system is rumoured to be modelled) has a little over 1,000 courts; we have nearly 16,500. American courts have less than 4,00,000 cases pending and add/dispose less than 3,00,000 cases a year. In India, we probably have over three crore cases pending; we add about 80 lakh cases and dispose of a little over 80 lakh cases every year. Just on a daily basis, the Indian court system generates about 15 lakh hearing-related records every work day, a huge number by any standard.

The e-courts mechanism is particularly well- structured for the litigant — s/he can see exactly what happened in a given hearing and when the next hearing is scheduled. And lawyers can use this information, too, for similar operational tracking. Further, with the National Judicial Data Grid summaries, people can see general statistics about how courts are doing — how many cases are being added every day or month, how many are being disposed and so on. So the system very clearly is of great value to the immediate participants that need data.

So what’s the problem here? The problem is not in the e-courts system itself, it is its inability — for now — to address the big picture. Over the last 66 years of having our own judicial system, Indian courts have consistently fallen behind on disposing cases in line with new cases being added. We now have about three crore cases pending across 42the country, adding even more as the economy and access to justice improve. At best, courts dispose about 25 per cent of pending cases every year and add nearly as many as that. That means about 2.2 crore cases that are not making any real progress every year. The rate of litigants filing new cases cannot be artificially stifled, either — the fact that the system is clogged cannot come in the way of someone’s right to justice. Obviously, there’s no way the court system can catch up — in fact, pendency will probably get worse over the near term. So what’s the solution?

A number of solutions have been discussed in recent times. Here are some of them:

1. Offloading minor operational tasks from judges to trained court personnel, so that the judge can focus on cases whose records are complete and can be disposed of quickly.

2. Pre-screening cases so only those that have litigants and representatives in place will actually appear in front of judges.

3. Creating alternate dispute resolution mechanisms, particularly for commercial disputes, so the overall caseload reduces.

4. Identifying specific stages in some types of cases that could be streamlined (or done away with), so overall court time is maximised.

5. Increasing the number of judges and filling vacant benches, so the system can run closer to planned capacity.

Designed correctly, each of these — and other — ideas can help reduce pendency. Some may make a big difference and even obviate the need for systemic changes. The challenge is to figure out which ones may work and which ones may not. In a system that is adding nearly 40,000 cases per day on average, even minor changes need analysis, design, piloting, tracking, and then scaling. And, during the implementation of such changes, all parties concerned must be able to see details of the change as it affects litigants: a registrar, for example, should be able to track the cases that s/he can review before placing them before the judge. With the data that the e-courts system already collects, this is all possible in the short term.

The data that the e-courts system has is rich and large but hugely distributed. Possibly because the system has been deployed over so many years, its data sits not in one or a few databases but in 4,000 different databases. There is currently no way, for example, for a non-technical person to compare the pendency of one court with that of another. The way the e-courts system has been implemented, it needs strong programming skills to extract any analyses other than the ones already available. Even small comparisons among courts need an understanding of the underlying database structures, their technical connections, their differences, esoteric structured query language (SQL), and finally, a supported programming language. Instead, by bringing all this data together under one large store that has analysis tools built in, all kinds of analyses suddenly become possible, by people who are not programmers but are knowledgeable about the justice system.

In general, data by itself is useless. To recognise the ‘data’ that 36ºC is the measure of temperature is pointless — knowing that it is that hot outside may mean that I decide to skip an outdoor lunch engagement — that is the power of ‘information’. With a common data store, the e-courts data can be interpreted and put in context in various ways, turning it into information that can then help all kinds of decisions. For example:

1. An analysis of, say, the cases in Madhya Pradesh may throw up a pattern of specific order types that could very well be decided by 43a trained non-judicial official in the Registry. Even if that amounts to 10 per cent of the cases that are heard every day, it is 10 per cent of the cases that a judge need not have to deal with, freeing him/her up for other judicial decisions.

2. An analysis of the reasons for deferral of cases may throw up a pattern of plaintiffs and respondents routinely delaying appearing in front of the judge. Other officers could then be trained to handle such situations, where only cases with ‘complete’ records will actually get the judge’s attention.

3. There may be certain types of commercial cases that take an unnecessarily large number of hearings relating to the commercial value of the cases themselves. It may be possible to move them to external arbitrators, leaving judges to focus on other matters.

As more of the data becomes available in easily accessible dashboards and charts, judges, and other court officers can make informed decisions on a daily basis — decisions that directly reduce pendency.

From a purely technical standpoint, the e-courts system may benefit from these enhancements, apart from tools for analytics:

1. A single physical database that has all the cases across the country in one, easily accessible store. The typical arguments against this model — too much data, multiple data models, having to collate data from multiple courts into a single numbering system, etc.— are all technical issues that have been solved in much larger contexts already. For example, cloud systems routinely deal with millions of records every hour, all packed into shared databases using auto-generated GUIDs.¹

2. Better controls on the inflow of data from the court systems. For example, the Andhra Pradesh courts routinely seem to submit data for cases from the 12th century, since local court systems seem to take pretty much any date keyed in. Automated data checks in the inflow process for realistic data can improve the quality of data and identify upstream problems easily.

3. A user interface that lends itself to mobile use. Consumers routinely access systems like e-courts on their phones, but the current e-courts system renders very badly on devices.

4. A navigation model that is more intuitive for the litigant. For example, a case number search right from the main page, so people do not have to click through five pages and several combinations before getting to their cases.

5. A more GET-oriented set of pages.² The e-courts site relies heavily on the HTTP POST protocol, even for what should obviously be just GET requests for data. While programmers may justify the POST because it updates (we assume) logs in some manner, simple GET requests perform better and lend themselves to all kinds of automation in the future.

6. An API³ model that outside agencies can use, for various purposes. Given the wealth of data that e-courts has, opening it up for other agencies — government and otherwise — via programmatic interfaces will engender a huge amount of collaboration, analysis, and general improvement in court systems.

The e-courts system is collecting a treasure trove of data right now. It is ideally suited to become the basis of tremendous progress in reducing pendency, 44as also overall improvements in the justice delivery system. It can also be the basis for all kinds of support programmes, where judges can help their officers and juniors to be tremendously effective very quickly. We only need to move from ‘data’ to ‘information’!

Notes

1. GUID stands for ‘globally unique identifier’, a randomly generated sequence of numbers and digits that, on their own, signify nothing but can be used to uniquely identify a case or a hearing or some such element. Contrast this with ‘human-readable’ identifiers such as a ‘case number’, where the first few characters identify the ‘case type’, the next four the year of filing, and the last digits a sequence number within the case type. Such identifiers become troublesome when the ambit of their use expands; for example, if you were to put cases from multiple courts into the same file, then you would need to add a ‘court name’ to the human-readable case number, since the same case number appears in multiple courts signifying different cases. With a system-generated GUID, no such overlap occurs.

2. GET and POST are technical methods by which Internet browsers (and other systems) communicate with websites. Typically, GETs are used to get data from a website and POSTs are used to change data in a website.

3. API stands for ‘application programming interface’, a way for computers to talk to each other.