The same patient exists four times
Front desk, lab, pharmacy and billing each keep their own record. When two of them disagree, a receptionist reconciles it by hand.
Healthcare
Healthcare software development, built for how Indian clinics actually run
Appointment engines, EMR, lab and pharmacy modules, ABDM-linked records, and the reports your medical superintendent actually asks for. Built to keep working through a Monday morning OP queue.
5 solution blueprints
17 systems we integrate
8–20 weeks, typical build
The starting point
What is usually broken before we arrive
Corrections leave no trail
A clinical note gets amended six weeks later. Without an amendment history the original is gone, and nobody can say who changed it.
The counter dies with the broadband
Most hospital software needs the network to bill a patient. A short outage means paper slips, and somebody re-keys them that night.
In plain terms
Healthcare software development means building what a hospital, clinic or diagnostic lab runs on. Patient registration, appointments, medical records, lab and pharmacy workflows, billing and claims. In India it also means building to the ABDM specification, linking records to ABHA numbers, and handling patient data under the DPDP Act.
Most hospitals do not run one system. They run four, plus a WhatsApp number the front desk uses for appointments. Each is fine on its own. The trouble starts when two of them describe the same patient differently.
So we settle identity first. One patient record that holds across OP, IP, lab and pharmacy is worth more than any dashboard. Everything downstream gets easier once that is fixed.
ABDM turned good practice into a written specification. ABHA linking, HL7 FHIR R4 exchange, NHCX claim settlement. We build to it from day one, because retrofitting an identity model is close to a rewrite.
What we build
Healthcare systems, and who builds each one
Every card links to the practice that does the work. Follow one if you want the detail.
Hospital and clinic management
OP and IP registration, doctor scheduling, EMR, discharge summaries, billing and MIS. One system, one patient identifier.
ExplorePatient apps and teleconsultation
Booking, digital prescriptions, report access, video consults and reminders on iOS and Android. Same record the hospital sees.
ExploreAI triage and clinical assistants
Symptom intake that routes to the right department, discharge summaries drafted from notes, claim documents read automatically. A clinician approves every output.
ExploreClinical and operational dashboards
Bed occupancy, average length of stay, lab turnaround by department, revenue by consultant. Refreshed nightly from the HIS, not assembled in Excel.
ExploreHospital ERP for pharmacy, stores and HR
Drug batch and expiry tracking, ward indents, duty rosters across shifts, and payroll that understands night allowance and on-call.
ExploreABDM, HL7 FHIR and HIS integration
ABHA linking, FHIR R4 mapping, HL7 v2 feeds from your existing HIS, DICOM handoff to PACS, NHCX claims. The plumbing between systems built to ignore each other.
ExplorePatient acquisition for hospitals
Local search for every branch, department landing pages, doctor profiles that rank. Campaigns measured on booked appointments, not clicks.
Explore Solution blueprints
Open one and see exactly what gets built
The situation it answers, the architecture, every module, the systems it plugs into and how long it takes. These describe our work, not one client's project. Named clients with measured results are in the case studies.
01 Multi-branch clinic: appointments and EMR 14–18 weeks
The situation
A group of four to eight clinics sharing a pool of visiting consultants. Each branch keeps its own appointment book. A patient who visits two branches exists twice. Consultants get double-booked because the branches cannot see each other calendars.
How it is built
React PWA for front desk and consultant screens. Node.js API over a PostgreSQL clinical store, Redis for the slot engine, role-based access across six roles. One VPS per group, with nightly encrypted backups held off-site.
Rules it has to follow
Patient data is handled under the DPDP Act. Consent is captured against a stated purpose and every read of a record is logged. Clinical entries are append-only, so a correction is recorded as an amendment and never overwrites the original.
Modules 10
- Central patient master with ABHA linking and duplicate merge
- Slot engine with consultant, room and equipment constraints
- OP registration, vitals capture and queue display
- Consultation notes with specialty-specific templates
- e-Prescription with drug master and interaction warnings
- Lab and radiology order entry with result attachment
- Billing, package handling and receipt printing
- Follow-up recall and no-show reminders
- Consent capture and access audit log
- Branch-level and group-level MIS
Plugs into
- ABDM / ABHA gateway
- HL7 FHIR R4
- WhatsApp Business API
- Razorpay
- MSG91 DLT SMS
02 Diagnostic lab: order to report 12–16 weeks
The situation
A pathology and imaging lab with collection centres feeding a central unit, plus home-collection phlebotomists. Sample identity lives on handwritten labels. Reports go out as email attachments. Nobody can produce turnaround time for one test on one day.
How it is built
Barcode-first sample tracking on a Node.js API with PostgreSQL. React technician console for result entry and verification. Android app for phlebotomist routes. Patient reports are served through signed links that expire.
Rules it has to follow
A report cannot be released until a pathologist verifies it, and the signing credential is recorded against every release. Calibration, internal QC and reference range revisions are kept with full version history for NABL audits.
Modules 10
- Test master with panels, methods and reference ranges
- Barcode sample registration and chain-of-custody tracking
- Home-collection scheduling and phlebotomist routing
- Analyser result capture with technician and pathologist verification
- Auto-flagging of critical values with escalation
- Digitally signed PDF reports and patient portal access
- Turnaround-time tracking by test, department and shift
- Reagent and consumable stock with expiry alerts
- B2B rate cards for referring clinics and corporates
- Referral and commission settlement
Plugs into
- Analyser interfaces over HL7 v2 / ASTM
- DICOM to PACS
- ABDM / ABHA gateway
- Google Maps Routes API
- Razorpay
03 Hospital ERP: pharmacy, stores, HR and payroll 16–20 weeks
The situation
A 100 to 250 bed hospital where the clinical system came from one vendor and everything behind it runs on spreadsheets and Tally. Ward indents are paper chits. Drug expiry is discovered at the counter. Payroll takes four days.
How it is built
Modular ERP sharing the hospital employee and item masters, on Node.js and PostgreSQL. The pharmacy counter runs offline-capable, so it keeps billing through a network drop and syncs when the line returns.
Rules it has to follow
Schedule H and H1 sales are recorded against the prescriber and the prescription reference. GST e-invoices are raised at the point of billing, not reconciled monthly. Payroll deductions follow EPFO and ESIC schedules.
Modules 10
- Drug and consumable master with batch, expiry and rack location
- Ward indent, issue and return workflow
- Pharmacy point of sale with offline mode
- Purchase orders, GRN and supplier ledger
- Expiry and near-expiry alerting with return-to-supplier
- Duty roster across shifts, departments and on-call
- Attendance from biometric devices with exception handling
- Payroll with night allowance, on-call and statutory deductions
- Asset register with preventive maintenance schedules
- Department-wise consumption and cost reporting
Plugs into
- Tally ERP
- Biometric attendance devices
- GST e-invoicing (NIC IRP)
- Hospital HIS via HL7 v2
04 Patient app with teleconsultation 12–16 weeks
The situation
A hospital with a working HIS but no direct line to patients. Appointments arrive by phone calls the desk cannot always answer. Nobody knows whether discharged patients came back for follow-up. Reports are collected in person.
How it is built
React Native app for iOS and Android, talking to the existing HIS through a purpose-built integration API. WebRTC video consults, scheduled push notifications, and a document service that issues expiring signed links instead of public report URLs.
Rules it has to follow
Teleconsultation follows the Telemedicine Practice Guidelines. Practitioner identity is displayed, consent is recorded at the start of the consult, and prescriptions stay inside the permitted list. Report links expire and are never publicly addressable.
Modules 10
- Registration with ABHA creation and linking
- Doctor and department discovery with live slot availability
- Appointment booking, rescheduling and cancellation
- Video consultation with in-call notes and prescription issue
- Digital prescription and report vault
- Medication and follow-up reminders
- Care-plan tracking after discharge
- Family profiles under one account
- In-app payment and invoice history
- Feedback capture routed to the department head
Plugs into
- Existing HIS via HL7 FHIR R4
- ABDM / ABHA gateway
- WhatsApp Business API
- Firebase Cloud Messaging
- Razorpay
05 Clinical and operational analytics 8–12 weeks
The situation
A management committee that gets a monthly MIS pack stitched together by hand from four systems, arriving three weeks after the month closes. Nobody argues with the numbers because nobody can reproduce them. Questions raised in the meeting take another month.
How it is built
Nightly extraction from the HIS, LIS and pharmacy databases into a PostgreSQL warehouse with a modelled star schema. Surfaced in Power BI with row-level security, so a department head sees their department and the director sees everything.
Rules it has to follow
Reporting datasets are de-identified wherever the question does not need a named patient. Access to identifiable extracts is restricted by role and every access is logged.
Modules 10
- Bed occupancy and average length of stay by ward
- OP footfall, OP-to-IP conversion and referral source
- Lab turnaround time by test, department and shift
- Revenue and margin by consultant, department and package
- Pharmacy consumption, stock-out and expiry write-off
- Insurance claim ageing and rejection reasons
- Theatre utilisation and cancellation reasons
- Readmission tracking within defined windows
- Row-level security by department and role
- Scheduled distribution of the committee pack
Plugs into
- HIS and LIS databases
- NHCX claim data
- Tally ERP
- Power BI Service
Regulation
What healthcare software has to comply with in India
Get these wrong and the build is not late, it is unusable. They are design inputs on day one.
ABDM and ABHA
The Ayushman Bharat Digital Mission sets how health records are identified and exchanged nationally. You register the facility and its practitioners, create or link ABHA numbers, and share records through the consent-manager flow instead of direct database access.
DPDP Act 2023
Health data is personal data under the Digital Personal Data Protection Act. In practice: consent captured for a stated purpose, retention limits actually enforced, breach notification readiness, and the ability to produce or erase a patient record on request.
HL7 FHIR R4 and HL7 v2
FHIR R4 is the ABDM exchange format. Most installed Indian HIS and analyser equipment still speaks HL7 v2 or ASTM. Any build touching existing hardware needs both, plus a mapping layer that does not quietly drop fields between them.
Telemedicine Practice Guidelines
Remote consultation carries its own obligations. Verify the practitioner registration, record patient consent, restrict which medicines may be prescribed remotely, and keep the consultation record on the same footing as an in-person visit.
NABH and NABL documentation
Accreditation audits ask for evidence, not assertions. Incident registers, calibration logs, internal quality control records, version history on reference ranges. Systems that produce this as a by-product of daily work survive audits comfortably.
Why Naryon Tech
How we approach healthcare projects
- The audit trail comes firstClinical corrections, consent changes and record access are logged from the first sprint. Add an audit log after a year of running and that year stays unexplainable.
- One patient identity everywhereMost hospital software pain traces back to one patient existing four times. We solve identity at the centre, with duplicate detection and a merge workflow, before building anything on top.
- Counters that survive an outageOP registration and pharmacy billing work offline and sync on reconnect. A broadband drop should slow a hospital down, not stop it.
- Designed with the people at the counterFront-desk staff hit these screens hundreds of times a day. We sit with them during discovery, and the keyboard-first flow usually beats the prettier layout.
Tooling
What we build healthcare systems with
Application
- React
- React Native
- Node.js
- TypeScript
- Astro
Data
- PostgreSQL
- Redis
- Power BI
- Azure Data Factory
Health standards
- HL7 FHIR R4
- HL7 v2
- DICOM
- ICD-10
- SNOMED CT
Infrastructure
- Docker
- Nginx
- Encrypted backups
- Role-based access control
Working from Chennai and Trichy, with clients in
- Chennai
- Tiruchirappalli (Trichy)
- Coimbatore
- Madurai
- Salem
- Erode
- Tirunelveli
- Vellore
- Tiruppur
- Puducherry
Straight answers
Healthcare: what people ask us first
Can you integrate with the HIS we already have?
Usually yes. Most installed Indian HIS platforms expose an HL7 v2 feed, a database view, or a vendor API, and we build against whichever exists. Where a vendor will not open anything, a staged replacement is honestly cheaper than fighting it. We will say so in discovery, not afterwards.
What does ABDM compliance actually involve?
Register the facility and its practitioners in the ABDM registries. Create or link ABHA numbers at registration. Store records so they map cleanly onto FHIR R4 resources. Handle data requests through the consent-manager flow. Most of the effort sits in the record model, which is why designing for it beats retrofitting it.
How is patient data protected under the DPDP Act?
Consent is stored with the record against a stated purpose, never assumed. Access is restricted by role and every read of an identifiable record is logged. Data is encrypted in transit and at rest. Retention is enforced by scheduled jobs, and there is a defined process for producing or erasing a patient record on request.
Do you build for single clinics or only hospitals?
Both, but the shape differs. A single clinic usually needs appointments, records, billing and reminders, and goes live in eight to ten weeks. A multi-branch group needs central patient identity, cross-branch scheduling and consolidated reporting. That is where the fourteen to twenty week ranges above come from.
Does it work when the internet goes down?
The counters that cannot stop are built to keep going. OP registration and pharmacy billing hold transactions locally and sync when the connection returns, with conflict handling for the rare record that changed on both sides. Reporting and integrations catch up afterwards. Those can wait. A patient queue cannot.
Who owns the code and the data at the end?
You do. Source code is handed over in your own repository. Infrastructure runs in your account or on hosting you control. The database is yours, with documented schema and export routines. Nothing in the contract makes leaving expensive, because holding clinical data hostage is not a retention strategy we use.
Close to this
Related industries
Building something for healthcare?
Tell us the workflow that keeps breaking. We will say honestly whether software fixes it, and what it would take.