01 · What breaks
Design for the failure modes, not only the happy path.
Disability records drift easily into a list of what is wrong with someone. The result is a file that feels intrusive to the person, gets little use from staff and says nothing about whether inclusion improved.
Diagnosis used as identity
When the first field on every screen is a disability type, staff and reports start to see a category instead of a person. Put name, goals and communication needs first. Keep disability category and certificate details in a restricted section, opened only where an entitlement or service requires them.
Collecting impairment detail without purpose
Medical histories, percentages and clinical notes are tempting to capture for completeness. Each is sensitive health information and rarely changes what a field team does next. Record the functional need that drives a support, and point to an external certificate rather than copying its contents into the case.
Accommodation marked complete before use
A wheelchair delivered, a hearing aid fitted or a school ramp approved is not the same as one in use. Keep provided and in use as separate statuses, with a follow-up check after an agreed period. Devices are often abandoned because nobody came back to adjust them.
Inaccessible forms and communication
A case system that sends text-only SMS to a blind participant, or a dense consent form to someone with an intellectual disability, shuts out the people it serves. Test every screen, message and printout with disabled users, and store each person's preferred format so the system uses it automatically.
02 · Minimum viable model
Organise each plan around goals, barriers and supports.
These six records place the barrier in the environment and make the plan about removing it. They also follow case management rather than batches, because each person's goals, supports and review points move at their own pace.
| India touchpoint (as of October 2026) | What the law or system says | What the case record should hold |
|---|---|---|
| Specified disabilities | The Rights of Persons with Disabilities Act, 2016 recognises 21 specified disabilities. | The category only where a scheme, certificate or accommodation request needs it, in the restricted section |
| Benchmark disability | A person with benchmark disability has not less than 40% of a specified disability, as certified. | Certified status (yes, no, pending) and the certificate date, not the medical report |
| UDID card and certificate | Both are applied for through swavlambancard.gov.in. | Application status (not started, applied, issued) and date; the number only if a service uses it |
| Children in the programme | India's DPDP Act, 2023 requires verifiable consent of a parent or lawful guardian before a child's personal data is processed. Most of these duties apply from around May 2027, as of October 2026. | The guardian's consent with date and version, plus the child's own agreement recorded in a format they understand |
Eligibility rules for schemes and concessions change and differ by state. Confirm them with the relevant department or a legal adviser before the system uses them to prompt an application.
03 · Implementation sequence
Move through reviewable gates.
Co-design comes first here because the people using the record include disabled participants and their families, not only staff. Each step ends with something a disabled reviewer has tested.
Co-design language and access needs
Agree the terms the record will use with disabled people's organisations or participant groups, and drop labels they find offensive. Decide which formats the system must support, such as voice notes, large text or interpreter scheduling. Leadership signs off the language guide before any form is built.
Record goals before service categories
The intake screen asks what the person wants to do and where, before any service or impairment field appears. A goal such as travelling to college independently points staff towards mobility training, a travel concession and a route check. A service menu shown first narrows what gets offered.
Map barriers and accommodations
For each goal, list the barriers (physical, communication, attitudes, policy) and the accommodation or assistive product that addresses each one. Link every accommodation to who provides it, its cost and a due date. This is the plan the person sees, so produce it in their preferred format.
Assign and follow referrals
Referrals to therapy, assessment camps, schools or employers carry a named receiver, a due date and a status that the receiving side confirms. If a certificate application or a device request stalls, the case worker sees it on a weekly list instead of discovering it at the next visit.
Review whether participation changed
At each review, ask the person whether the goal moved: attending more often, doing the task with less help, reaching the place. Record their answer alongside the staff observation. Where the two disagree, keep the person's view on the record and adjust the plan.
Give people a correction route
Participants and guardians can see their record and correct what is wrong, through a route that works for them: a visit, a call or an accessible form. A named data owner logs each request and the response. Corrections count towards data quality, not complaints.
04 · Evidence
Measure whether the work became clearer.
These measures move attention from services counted to participation achieved. Most M&E software can show them, provided the follow-up check exists in the record.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Goal-first intake and plan templates
- Provided versus in-use status tracking
- Referral reminders with confirmation
- Plans and messages in each person's format
People should decide
- Clinical diagnosis
- Eligibility and benefit decisions
- Accepting an accommodation as adequate
- Sharing sensitive functional information
06 · Common questions
Practical questions teams ask.
Questions inclusion teams and programme managers raise when moving case files off paper.
What should a disability inclusion case management system track?
It should track the person's goals, the barriers in their way, the accommodations and assistive supports provided, referrals to other services and whether participation actually changed. Diagnosis and certificate details sit in a restricted section and are used only where a scheme or service needs them. The plan itself should be readable by the person it describes.
How is an inclusion case record different from a therapy record?
A therapy record follows sessions and clinical progress within one service. An inclusion case record follows a person across services and settings: school, work, transport, community life. It can link to therapy notes without copying them. The question it answers is whether the person is taking part in what they chose, not how many sessions they attended.
Should we record the type and percentage of disability?
Only where it changes what happens next, such as a certificate application, a scheme or a specific accommodation. Record whether a certificate exists and its status, and restrict who can see the category. Percentages and medical details rarely help a field team plan support, and holding them increases the harm if the record is ever exposed.
How do you make a case management system accessible to disabled participants?
Test it with them. Check that messages work with screen readers, that voice and large-text options exist, that consent is explained in easy-read form and that sign language interpreters can be booked. Store each person's preferred format in their profile and have the system use it for reminders, plans and feedback requests.
Can a small disability organisation do this without a big system?
Yes. A short goal and barrier form, an accommodation list with provided and in-use statuses, and a monthly review can start in a simple low-code app or a well-structured spreadsheet. What matters more than the tool is restricted access to sensitive details and a follow-up check on every support that was provided.