Deployment & data ownership
Hospital Software Hosted Under Your Control
Most hospital software is sold as a shared service: your patients’ records sit in the vendor’s database alongside every other hospital’s, in a region the vendor chose, under access the vendor controls.
auraCare is deployed the other way round. Each hospital gets an isolated instance in a cloud space it chooses, and we hold no copy of its records.
Two hospitals, two environments, no connection between them. Support access is granted per task and appears in your audit trail.
What “self-hosted” actually commits us to.
The phrase is used loosely in this market, so here is precisely what it means for an auraCare deployment.
- Your deployment is a separate instance. There is no shared multi-tenant database of patient records and no pooling of records across hospitals.
- You choose the cloud environment and the region it runs in, which is how a hospital subject to Indian data-localisation requirements satisfies them.
- We do not hold patient records of our own, and we have no standing access to yours.
- Where access is needed for support, implementation or diagnosing a fault, you grant it — limited to the task, time-bound so far as practicable, and recorded in the audit trail.
- The arrangements for a deployment, including region and infrastructure provider, are written into the agreement before any patient data is processed.
Why hospitals ask for this.
The commercial reason is leverage. A hospital whose records live only in a vendor’s database has limited room to renegotiate, and a difficult exit. When the database is yours, the relationship is about whether the software is good.
The regulatory reason is location. Health data created in an Indian hospital is subject to Indian requirements, including the ABDM Health Data Management Policy and the CERT-In directions on keeping logs within Indian jurisdiction. Choosing your own region is the simplest way to satisfy that.
The operational reason is blast radius. A shared platform means an incident at another hospital can become your incident. Isolated deployments do not share that fate.
And the practical reason is that hospitals already run infrastructure. Most have somewhere to put this, or a cloud account they already pay for, and would rather use it than add another external dependency.
What actually runs in your environment.
A deployment is a small, conventional stack. Nothing about it requires a specialist to operate day to day.
The exit matters as much as the entry.
Any hospital committing its operations to a system should ask what leaving looks like before it starts, not after.
Your database, not a copy of it
Because the database is in your environment, you already hold the records. There is no request to make and no export to wait for.
Open, documented storage
Records live in PostgreSQL under a schema we document, rather than an opaque proprietary store, so they can be read without our involvement.
Migration in both directions
The same work that brings records in from a previous system can take them out to a next one. It is not a capability we only build in our own favour.
No hostage data
Ending the relationship does not put your operational history behind a paywall or a support ticket.
Questions hospitals ask about hosting.
Does this mean we need our own IT team?
Not a large one. A deployment is a standard application and a PostgreSQL database, and most hospitals either have someone who manages their existing servers or already hold a cloud account. We handle installation and updates; what you hold is the environment and the data inside it. The distinction that matters is ownership, not who runs the routine operations.
Can it run on our own servers rather than a cloud?
The model is the same either way: an isolated instance and a database you control. Whether that sits in a cloud account or on hardware in your building is a question of what you already run and what you want to maintain, and it is decided per deployment and recorded in the agreement. Talk to us about what you have before assuming either answer.
How do you support software you cannot see?
By being granted access when it is needed rather than holding it permanently. You give access for a specific task, it is limited to what that task requires, it is time-bound so far as practicable, and it appears in the audit trail like any other activity. Standing vendor access to live patient records is convenient for the vendor and difficult to justify to anyone else.
Tell us where you would want it to run.
Deployment questions are easier to answer with specifics: what infrastructure you already have, what your data-localisation obligations are, and who would hold the credentials.
We will tell you what a deployment in that environment looks like, including what we would need from you.
Hosting arrangements are written into the agreement before any patient data is processed.