Product auraCare HMSPatient JourneyOPDQueues & Tokens
Solutions
Deployment Self-Hosted HMISSecurityImplementationProduct Status
Resources GuidesWhat is an HMS?HMS vs HMISDepartment handoffsReducing OPD waitingCloud vs on-premise
Company AboutContactPrivacy
Book a demo

Deployment & trust · Updated 28 August 2026

Product Status: What Is Built, and What Is Not

Software companies usually make a buyer work to find this out. It is on one page here, because a hospital committing its operations to a young product should be able to establish the position in a few minutes rather than across three meetings.

The distinction that matters through all of it: implemented and demonstrable is not the same as proven in production. auraCare is a long way into the first and at the beginning of the second.

Implemented

What is implemented and can be demonstrated.

These are working surfaces in the application, not a roadmap. Ask to be shown any of them in a demonstration, against your own workflow.

  • Arrival and registration: token kiosk, reception desks, patient identity, returning-patient matching, appointment check-in.
  • Queues and displays: per-service-point queues, token policies and numbering, token stations, waiting-area displays, call, recall, hold and no-response handling.
  • Clinical work: triage, vitals, doctor worklists, consultation, care plans, and a per-role work list rather than a shared inbox.
  • Orders and diagnostics: orders raised from a consultation, laboratory and imaging worklists, results, and review that becomes actionable when a result lands.
  • Pharmacy and billing: dispensing against the visit, charges arising from work performed, checkout and payments.
  • Inpatient: admission, bed management and transfers, ward tasks, nursing, discharge.
  • Theatre and appointments: scheduling, case readiness, and appointment booking, cancellation and check-in.
  • Administration: organisation, locations, departments, services, service points, team and roles, pathway configuration, reporting, and an audit trail of activity.

What is not built, and what that means.

Anything marked CONCEPT or ROADMAP in a demonstration or on this site does not exist. It is shown to describe direction, and it is labelled so nobody mistakes it for a shipped screen.

  • ABDM functionality is not available in any deployment. No ABHA number, ABHA address, consent artefact or health-information-exchange data is processed by auraCare today.
  • Multi-factor authentication is not implemented. Neither is application-level rate limiting, nor application-level encryption at rest beyond what the database and the hosting environment provide.
  • Parts of the patient-facing application are shown as concepts. Where a screen carries a CONCEPT flag, it is a design direction and not a capability you can buy.
  • There is no published integration catalogue. Interoperability beyond the deployment itself is a conversation to have per hospital rather than a claim we make here.

How many hospitals run auraCare in production.

None yet. auraCare has not run a hospital in production, and we would rather you knew that before the first meeting than after the third.

What exists instead is the thing that shaped the product: it was built alongside a working charitable hospital in rural West Bengal, against that hospital’s real workflow, constraints and daily realities. That is where the patient-journey model came from, and it is why the operational detail on this site reads as it does.

Which means the honest way to evaluate auraCare is not to ask for a reference list we do not have. It is to bring your own workflow — a normal Monday in your busiest department — and watch it run, including the parts where it does not fit.

The first production deployments will be stated here when they exist, with the hospital’s permission, and this page will say so before any sales page does.

Certification, accreditation and regulatory position.

Stated in the same terms as the privacy policy, which is the binding version.

  • auraCare is independently developed by Nrisimha Tech Solutions and does not currently hold third-party product certification, accreditation or regulatory endorsement.
  • auraCare is not certified, accredited, approved, empanelled or endorsed by any healthcare institution, regulatory authority, standards body or government body, except where we state otherwise expressly and in writing.
  • No regulator has assessed auraCare. Where we reference a law or a standard, we distinguish what we build to from what anyone has externally assessed.
  • ABDM registration is under application and has not been granted. No deployment is connected to ABDM.
  • Compliance is a property of your deployment and your practices as much as of the software. Treat any vendor claiming to make you compliant by installation with suspicion.

Who stands behind it.

Relevant to a procurement assessment, so it is stated here rather than left to be discovered.

  • auraCare is built by Nrisimha Tech Solutions, a sole proprietorship registered in India, and it is the only product the company builds.
  • During evaluation and implementation, hospitals work directly with the team responsible for the product rather than through an intermediary.
  • Support access to a deployment is granted by the hospital per task rather than held permanently, and it appears in the audit trail.
  • The hosting arrangement, including region and infrastructure provider, is written into the agreement before any patient data is processed.

How to verify any of this.

None of the above should be taken on trust, including from us.

01

Ask to be shown it

Every capability listed as implemented can be demonstrated against your own workflow. If something cannot be shown, treat it as not built.

02

Ask for the registration

For ABDM, ask any vendor whether registration has been granted and ask to see it. “ABDM ready” and “ABDM compliant” are marketing phrases with no defined meaning.

03

Read the security page

It states the specific controls that exist and names the three that do not, rather than describing the product as enterprise-grade.

04

Read the privacy policy

It is the binding version of the deployment, data-handling and ABDM positions summarised here, and it is written to be read rather than to be skipped.

Evaluate it against your own workflow.

The useful evaluation of a young product is not a reference call. It is watching your busiest department’s normal morning run in it, and seeing where it holds and where it does not.

Bring that morning. We will show you both.

This page is updated when the position changes, and carries the date it was last reviewed.