NABH Digital Health Standards for HIS and EMR Procurement

Read the current published edition rather than a summary, because the chapter structure evolves. Broadly, the requirements cluster around patient identification and record integrity, clinical documentation and orders, medication management, access control and privacy, audit and traceability, interoperability and data exchange, availability and continuity, and the system development and support practices behind the product. Each cluster maps to something a hospital already cares about, which is why the standard reads as sensible rather than bureaucratic once you get into it.

The requirements that most often expose a product are the unglamorous ones. Does the system maintain a single patient identity across departments and prevent silent duplicate creation. Does it record who viewed a record, not only who changed it. Can a clinician correct an entry without the original disappearing. Does it enforce role-based access at the field level where it matters, or only at the menu level. Can it export a complete, structured record for a patient rather than a set of screens rendered to PDF.

The other cluster worth pressing is continuity. Does the vendor support a defined recovery objective, does the architecture permit a standby, is there a documented downtime and recovery procedure, and has it been exercised with any customer. Vendors answer this in principle very readily. Ask for the name of a customer who has actually performed a failover on the product, and the tone of the conversation usually changes in a useful way.

Separately from the quality standards, the National Health Authority operates a sandbox and milestone certification process for software that integrates with the Ayushman Bharat Digital Mission. Vendors advertise the milestone they have achieved, and it is a genuine artefact you can ask to see rather than a self-declaration. Ask for the certificate, the milestone level, the date, and the specific product and version it was granted against, because a certification held by a different product in the vendor's portfolio is not the same thing.

What it proves is that the product has demonstrated defined integration capabilities against the mission's own environment. What it does not prove is that the capability is enabled in the version you will be buying, that it will work against your existing patient index, or that your hospital is registered and configured to use it. Several hospitals have bought certified software and then discovered that facility registration, health professional registration and internal workflow changes were entirely their own project.

So separate the two workstreams in the plan and in the contract. The vendor delivers the technical capability and demonstrates it in your environment against agreed acceptance criteria. The hospital delivers registration, workflow design, staff training and the consent process at the counter. Both have dependencies on the other, and the projects that go badly are almost always the ones where the hospital assumed the certificate meant the whole thing was the vendor's responsibility.

Vendors will offer an ISO 27001 certificate and sometimes an independent service auditor report. Both are useful and both are routinely misread. On the ISO certificate, read the scope statement, not the logo. A certificate whose scope covers the corporate head office but not the data centre or the development function tells you very little about the product you are buying. Ask for the statement of applicability and the certificate validity dates, and check the certification body is accredited.

For a service auditor report, distinguish a point-in-time design assessment from one that tests operating effectiveness over a period, and read the exceptions section, which is where the information is. A report with no exceptions across a twelve-month period on a complex service is unusual enough to be worth asking about. Also check the report covers the specific service you are buying, since large vendors scope these reports narrowly.

Then ask for something that is not a certificate at all: evidence of recent penetration testing on the product, with the scope, the date, the testing organisation and a summary of findings and remediation. You will not usually receive the full report, and that is reasonable, but a vendor who cannot produce even a summary letter has probably not had a test. Ask also how vulnerabilities reported by customers are handled, with a stated timeline for critical fixes, and get that timeline into the contract.

The most common tender failure is a requirement written as an adjective. Asking for a secure, standards-compliant, scalable system produces ten bidders who all say yes and gives the evaluation committee nothing to score. Write each requirement so that it names an artefact to be submitted or a behaviour to be demonstrated, and state how it will be evaluated. That single change does more for procurement quality than any amount of additional length in the document.

Structure the requirements into mandatory qualification criteria and scored technical criteria. Mandatory criteria are the ones where a no ends the bid: certifications you require, data hosting in India, a signed data processing agreement, breach notification within a period aligned to your own six-hour CERT-In obligation. Scored criteria are where you compare: demonstrated behaviours, integration track record, support model, exit and data portability terms. Keep the mandatory list short, because an over-stuffed one eliminates good suppliers on technicalities.

Include the commercial protections in the tender rather than negotiating them afterwards, when your leverage has gone. Data portability on exit in a structured format at a defined price. Source code escrow if the supplier is small. Service levels with meaningful remedies. A named implementation team. A cap on annual maintenance escalation. Suppliers price these when they are in the tender and resist them when they arrive after award, which is a straightforward reason to put them in early.

Control the demonstration or it will control you. Send every shortlisted vendor the same scripted scenarios drawn from your own workflows a week in advance, and require them to perform those scenarios on their system in front of your users. Registration of a patient with no identity document. An emergency admission where identity is established later. A verified laboratory result amended after release. A discharge summary generated and exported. A user whose role changes mid-shift.

Put the right people in the room and give them a scoring sheet. A registration clerk will notice in ninety seconds that a workflow takes eleven clicks. A staff nurse will notice that the drug administration screen requires scrolling to see the next dose. A medical records officer will notice that the amendment history is not visible to the person who needs it. These observations are worth more than the committee's collective impression, and they are only captured if the users are asked to score specific things rather than to give a general view.

Then verify independently. Call two reference hospitals of similar size that the vendor did not choose for you, and ask about implementation timelines against plan, support responsiveness at 2am, how upgrades are handled, and what they would do differently. Ask whether the reference site has ever performed a data export. HealUDoc and every other serious supplier should be comfortable with that level of scrutiny; discomfort is itself informative.

A tender requirement that does not survive into the signed agreement has achieved nothing, and this is where good procurement processes most often leak. Check the executed contract line by line against the tender and the bid response, and where the vendor's response made a commitment, ensure it appears in the agreement or in an annexure incorporated by reference. Marketing statements made during evaluation are not contractual unless somebody makes them so.

Tie payment to demonstrated acceptance rather than to elapsed time. Define acceptance criteria for each milestone in terms someone can test, include the certified capabilities among them, and retain a meaningful proportion until the system has run in production for an agreed period. This is standard practice in most industries and is unusually often absent in hospital software contracts, where payment schedules tend to follow the calendar.

Then set up the ongoing governance, because certifications lapse and products change. Ask annually for current certificate status, the sub-processor list, evidence of the most recent penetration test, and confirmation of the hosting region. Keep those documents in the same file as your NABH evidence, since an assessor asking how you assure yourself of your information system supplier will accept a maintained file and will not accept a recollection of what was checked at purchase four years ago.