What a clinical record has to be structured like for a doctor to understand a returning patient in the time between the patient sitting down and the consultation starting — including records created somewhere else entirely.
Three different problems. Most systems only solve the first.
In a busy Indian OPD, the realistic window between one patient leaving and the next being understood is well under a minute. Everyone building hospital software knows this, and almost everyone responds to it by making search faster. But a doctor who opens a record in 0.4 seconds and then scrolls through forty-one chronological entries has not saved any time at all. The thirty-second constraint is not about how fast the record loads. It is about whether the record was ever organised for reading.
Retrieval
Getting the right patient's record onto the screen. Largely solved by any competent system — search by name, phone number, UHID or ABHA address, with duplicate detection so the same patient does not exist three times.
Summarisation
Turning a longitudinal record into something a clinician can absorb in a glance. This is a design decision, not a technical one: what appears above the fold, what is grouped, what is collapsed. It is where nearly all of the thirty seconds is won or lost.
Reconciliation
Merging what your hospital knows with what other providers know — records pulled through ABDM, an old discharge summary from another city, a scanned report the patient carried in. A history that is only complete inside your four walls is not a full history.
The distinction matters because hospitals shopping for software usually test the first, assume the second, and never ask about the third.
What belongs on the first screen
Identity and the one-line clinical banner
Name, age, sex, UHID, ABHA linkage status, and — critically — allergies and any high-alert condition, pinned so they cannot be scrolled past. If a doctor has to click to find out about a drug allergy, the design has failed regardless of how fast the click is.
Active problem list
Current, ongoing diagnoses, distinct from the history of resolved ones. Most systems store diagnoses as a flat chronological list, which forces the doctor to reconstruct "what is actually wrong with this person now" from a stream of visit-level entries.
Current medications, with start dates
Not every drug ever prescribed. What the patient is on today, who started it, and when. This single element is the most common source of a doctor spending three minutes on something that should take five seconds.
Last three encounters, compressed
Date, department, presenting complaint, diagnosis, outcome — one line each. Three lines that tell a doctor the recent trajectory are worth more than full notes they have no time to read. Full notes stay one click away.
Recent investigations, with trend
The most recent results for the tests that matter in this patient's context, shown as a trend rather than a list. HbA1c across four visits is a clinical fact; four separate HbA1c reports are four documents.
Vitals trend
BP, weight, sugar, and whatever else the specialty depends on, plotted rather than tabulated. A graph is read in one second; a table is read in fifteen.
Admissions and procedures
A compact timeline of hospitalisations, surgeries and procedures with dates. This is the spine of the history and the thing most often buried inside document folders.
Outside records, clearly marked as outside
Records fetched through ABDM from another provider must be visible in the same timeline, and visibly labelled as external with their source. A doctor makes different decisions about a lab value from their own hospital than about one from an unknown facility, and the interface has to preserve that distinction.
Open items
Pending results, unfilled referrals, follow-ups the patient did not attend, unactioned advice. These are the things a doctor is most likely to miss and most likely to be asked about.
Everything else, one click deep
Full notes, scanned documents, old prescriptions, billing, insurance. Completeness is a requirement of the record. It is not a requirement of the first screen — and confusing the two is the most common design error in hospital software.
What "under 30 seconds" actually means in practice
Concretely: the doctor opens the patient, and without scrolling or clicking sees who the patient is, what they are being treated for, what they are taking, what happened at the last three visits, and which numbers are moving in the wrong direction. Anything they then want to verify is one click away and returns instantly. Nothing important is hidden behind a tab.
Two conditions have to hold underneath that screen. First, the data has to be structured — diagnoses, drugs and results captured as fields rather than as free text buried in a note, because a summary can only be assembled from data the system can actually read. Second, the patient's record has to be one record: linked across departments, across locations, and across providers via their ABHA, rather than three partial records that each look complete on their own.
The Reality Check: This is also why "we scan everything into PDF" does not reach thirty seconds. A scanned document is retrievable but not summarisable. It moves paper into a computer without making it readable at speed.
How LinkedCare helps
LinkedCare treats the first clinical screen as the product, not as a menu into the product. Allergies and active problems are pinned; current medication carries its start date and prescriber; the last encounters appear as a compressed timeline with full notes one click behind; vitals and key investigations render as trends rather than lists. Records retrieved through the patient's ABHA appear in the same timeline as your own, labelled by source, so the doctor sees one history rather than an internal record plus a separate ABDM inbox. Structured capture at the point of care is what makes that summary possible — which is why the entry design and the reading design are built as one thing.
Frequently asked questions
Does this need AI summarisation?
No — and starting there usually hides the real problem. Most of the thirty-second target is achieved by structuring data properly and designing the first screen well. AI summarisation adds most value on top of long, unstructured inpatient records; it cannot rescue a record where medications were never captured as medications.
What about patients with a very long history — twenty years, multiple comorbidities?
The principle is the same but the compression has to be sharper: active problems, current drugs, and a procedure timeline, with everything episodic collapsed by default. Length is exactly why the summary layer matters. A long record is unreadable chronologically no matter how fast it loads.
Can we really pull a patient's records from another hospital?
Through ABDM, yes — where the patient has an ABHA, the other facility is ABDM-linked, and the patient grants consent through their own app. The record arrives with a consent artefact defining purpose and duration. It is not universal coverage yet, and it should be treated as a growing supplement to your own record rather than a replacement for taking a history.
Is a scanned-document archive enough?
For medico-legal retention, largely yes. For thirty-second comprehension, no. Scans are retrievable but not structured, so nothing can be summarised, trended or checked against a prescription. Most hospitals need both, and the mistake is treating the archive as if it were the clinical record.