Skip to main content

Hospitals · Apps and custom software

Apps and custom software for hospitals.

Hospital software has to follow the patient, not the department: one hospital number from registration to discharge, a running bill that every department adds to as the work happens, and an insurance file assembled from the same record — with AI drafting the paperwork and clinicians making every clinical decision.
Get a quoteAbout Apps and custom software

Reviewed 2026-09-25Read as markdown

The market

How hospitals in India actually operate.

Most Indian hospitals below the corporate chains still run on a patchwork: a billing package bought years ago, registers for the wards, spreadsheets on the insurance desk and WhatsApp for everything in between. The expensive failures happen in the gaps — a pre-authorisation stalled for one missing document, a discharge held up by a bill nobody can finalise, a patient registered twice because the record lives in another department.

Workflow

The sequence we build around.

Named the way hospitals name it, because software that renames a business's own steps is software its staff argue with.

  1. Registration and the hospital number

    Every visit should hang off one number for the patient. In practice someone seen in OPD, sent for a scan and admitted a week later often ends up with three records, because each department registered them in whichever system it happened to have open.

  2. OPD consultation and orders

    The consultant’s orders — investigations, medicines, a referral — are where billing starts. When they are written on paper and re-keyed at the counter, the charge that goes missing is usually the one the hospital was least likely to notice.

  3. Admission, beds and the running bill

    Once a patient is admitted the bill grows by the hour: bed category, procedures, consumables, pharmacy issues. Families ask for the running total every day, and a system that can only produce it at discharge turns each of those questions into an argument.

  4. Insurance pre-authorisation and the TPA

    For an insured patient the cashless request, the query that comes back, the enhancement mid-stay and the final approval at discharge each need documents from three departments. The insurance desk is where a hospital’s paperwork problem becomes a revenue problem.

  5. Discharge and follow-up

    The discharge summary, the final bill and the follow-up appointment all have to finish before the bed is free. The summary is usually the bottleneck, because it waits for a doctor to write it from notes scattered across the whole stay.

Integrations

What it has to talk to.

Every one of these matters for a reason specific to hospitals. A list of connectors without those reasons is a feature grid.
Laboratory and imaging systems (LIS and PACS)
Investigations are ordered in the patient system and resulted in the lab’s or the imaging department’s own software. Without an interface the result is retyped or printed and scanned, the order never closes, and the bill carries a test whose report nobody on the ward can find.
Insurer and TPA portals, and the National Health Claims Exchange
Most insurers and TPAs still run portals of their own, and the government’s claims exchange is standardising the rest. The system’s job is to produce the pre-authorisation and claim file — diagnosis, estimate, investigations, notes — from the record, instead of the insurance desk rebuilding it by hand for every portal.
Tally or the hospital’s accounting system
Finance closes the month in accounting software, not in the patient system. Posting settled bills, advances, refunds and insurer receivables as they happen, rather than exporting a spreadsheet at month end, is what lets a hospital know on any given day how much insurance money it is still owed.
ABHA verification and the ABDM gateway
Registering the facility, verifying a patient’s ABHA number and sharing records with consent are optional for most private hospitals today and expected tomorrow. Building the fields and the consent flow into the first phase is cheap; retrofitting them into a record that never expected them is not.
Biometric attendance and duty rosters
Nursing and support staff rotate across wards and shifts, and payroll depends on who was actually on duty where. Tying the roster to attendance, and both to the ward each person was posted to, turns the monthly salary dispute into a report.

Constraints

What changes the build.

Regulatory and operational facts that decide what can be built, rather than what would be nice to build.
Rates have to be displayed
Clinical establishment rules in many states require a hospital to display what it charges for each service, in English and the local language. A billing system whose tariff lives in one place can publish the same figures to the counter, the estimate and the website instead of three versions that drift apart.
Insurance decisions now run on a clock
The insurance regulator’s 2024 master circular on health insurance puts clocks on insurers: a decision on a cashless request within an hour, and final approval within three hours of the hospital’s discharge request. A file sent incomplete comes back as a query, and the patient waits in the bed while the gap is filled.
ABDM is optional until it is not
Registering the facility on the Health Facility Registry and linking records to a patient’s ABHA number is voluntary for most private hospitals, but it is increasingly expected by government schemes and payers. A record designed with ABHA fields and consent flows from the start avoids a rebuild later.
Some registers are statutory
An obstetric ultrasound needs a Form F under the PC-PNDT Act, controlled drugs need their own register, and a medico-legal case needs its records kept for as long as the case can run. These are inspected, so they cannot be an afterthought bolted onto a billing package.
The hospital cannot stop when the internet does
Registration, the emergency desk and the pharmacy run through the night and through outages. A system that only works while the cloud is reachable is one the night staff will quietly replace with a register, so the counters that cannot stop need a local fallback that catches up when the connection returns.

Scope and timeline

What a build involves, and how long it takes.

Every project is quoted individually once we have understood the requirement — a fixed scope for a fixed price, with no rate card. These are the scopes we are usually asked for, and how long each typically takes.
Apps and custom software for hospitals — typical scopes
ScopeTypical timeline
First phase for one hospital: registration, OPD, billing and pharmacy12 – 20 weeks
Hospital ERP: admissions and beds, the insurance desk, lab and imaging interfaces, HR and payroll24 – 40 weeks

For a quote, tell us what you need. We come back with a fixed scope and a fixed price once we have understood it.

A worked example

One engagement, in three parts.

Context
The nearest system we have shipped is not a hospital’s. It is the custom ERP behind Curis 360, a Bengaluru physiotherapy practice with three clinics, home visits and online consultations, where patient balances had been kept in a register beside the booking software.
What was built
A patient system organised around the course of treatment rather than the single visit: sessions drawn down against what has been paid, each one attributed to the clinician who delivered it across three sites and home visits, and the month totalled as the work is logged.
What changed
The side register went, because the system that takes the booking now knows the balance. A hospital needs that same spine at a larger scale — one record per patient, charges posted where the work happens, staff attribution that feeds payroll — which is why a hospital build starts there and adds admissions and the insurance desk as later phases.

What goes wrong

The mistakes we see in hospitals.

Written down because they are the part of this page hardest to fake, and the part most worth reading before you commission anything.
  • Buying or building by department. A pharmacy package, a lab package and a billing package that each register the patient separately is how one person ends up with three hospital numbers, and every report the management asks for afterwards becomes a reconciliation.
  • Letting AI near a clinical decision. Drafting a discharge summary for the doctor to correct is paperwork; suggesting a diagnosis or a dose is a medical device, with the liability that goes with one. The line has to be designed into the system, not added later as a disclaimer.
  • Migrating every old file before go-live. Years of scanned records do not need to be structured to start. What matters on day one is that every new visit lands in the new system, with older files attached as documents and structured only when that patient returns.
  • Treating the insurance desk as a billing screen. Pre-authorisation, queries, enhancements and final approval are a workflow with deadlines, documents and owners, and a hospital that models them as a field on the invoice keeps chasing paper at the discharge counter.

Questions

What hospitals ask.

What does an AI-managed patient management system actually do in a hospital?

It takes clerical work away from people who should be with patients. It drafts discharge summaries from the notes of the stay for the doctor to edit and sign, pre-fills insurance forms from the record, flags a pre-authorisation file that is missing a document, shows which beds are likely to free up today, and sends follow-up reminders. Every clinical decision stays with the clinician.

Should a hospital build its own software or buy an existing HMS?

Buy, if a product fits how the hospital actually runs and the vendor will support it properly. Build when the hospital’s way of working is the product’s exception — several sites under one owner, an unusual tariff and package model, an insurance mix the product handles badly, or integrations no vendor will write for one customer. Our own Kinetiq Enterprise sits between the two, for multi-site clinics and hospitals.

Can the system keep working during an internet outage?

It should, at the counters that cannot stop: registration, the emergency desk and the pharmacy. A local server or an offline-capable client keeps them running and catches up when the connection returns. Everything that can wait — reports, analytics, the website — runs in the cloud.

What happens to old paper records and the previous software’s data?

Patient details and open bills move across before go-live, so nobody is registered twice. Older clinical files are attached to the record as scanned documents and structured only when a patient comes back. Retyping years of files before launch would delay the hospital by months for records most patients will never need again.

Who owns the software and the patient data?

The hospital does. The code is handed over in the hospital’s own repository, the database runs in an account the hospital controls, and nothing depends on MyFloww to keep working. Patient data is handled under the DPDP Act, with access by role and a log of who opened which record.

This page is also available as clean markdown with no navigation or styling, for anything that would rather read it that way. Last reviewed 2026-09-25 by Neel.

Where to next

Building custom app and web application development for a hospital?

Tell us what you are trying to do and we will come back with a scope and a number. Customer apps for Android, iOS and web, and the internal web application a business runs on — bookings, payments, inventory, staff, custom CRM and ERP.

Get a quoteMore for hospitals

Or message us on WhatsApp (opens in a new tab) · info@myfloww.in