The DPDP Act for hospitals: a plain reading

Nobody in your hospital runs the law. Yet you are being asked to sign off that the organisation will meet a new privacy regime.

Nobody in your hospital runs the law. Yet you are being asked to sign off that the organisation will meet a new privacy regime. The legal text is one thing; making it real at front desk, wards, labs, pharmacy, billing and IT is the hard part.

For a CEO or CFO, the practical questions start immediately: what data are we collecting, who is using it for what, where is it stored, and how do we prove that a patient’s permission was respected? If you cannot answer those in one sitting, you do not have an operational privacy model yet.

The operational problem, not the legal one

Your counsel will interpret the statute. Your job is to make sure everyday hospital work lines up with that interpretation. Think in terms of decisions your staff and systems take a thousand times a day: look up a record, print a report, export a list, push data to a lab or an insurer, train a model, answer a patient query.

Ask the uncomfortable questions:

• Before any use of personal data, can you show a record of permission that was consulted?
• If a use is not permitted, does the system refuse by default and escalate to a human?
• Is the minimum required data used for the task, or does the whole file travel by habit?
• Can you explain who saw what, when, and why, months later?
• If the hospital wants all data to remain in-region or on-premises, can your systems do that today?

Compliance is not a document. It is a steady drumbeat of small, provable decisions your hospital makes every day.

Why hospitals stumble

Hospitals are complex. Multiple software systems, departments that work around processes to get work done, vendors with their own access, and a growing set of analytics and AI initiatives. Even if the intent is right, drift happens when no single mechanism enforces consent before use, when exports are easier than audits, and when automation can act outside boundaries.

You do not need new lawyering to fix that. You need clearer guardrails, fewer uncontrolled paths, and evidence that the right checks actually ran.

What to do now, without buying anything

• Make permission a gate, not a form: insist that every system consult a consent record before using personal data. If the system cannot do that, make the human check explicit and auditable.
• Set deny by default for secondary uses: if a use is not explicitly allowed, it should not happen without a named approval.
• Minimise on purpose: for each workflow, define the minimum fields needed, and remove the rest from the screen, print and export paths.
• Decide where data may live: write down whether specific classes of processing must stay on-premises or in-region, and make vendors sign up to it.
• Inventory machine access: list every script, report, integration and model that touches patient or staff data, and tag each with a purpose and an owner.
• Record retention and access windows: set how long operational, analytical and model memories may keep personally identifiable data, and who may read them.
• Practice the exception path: when a use is blocked, who can approve it, how fast, and what trail is kept.

Where Ospia fits

Ospia is an AI-native hospital operating system that treats privacy as an operational control surface, not an afterthought. Three design choices matter here.

• Consent before use: Ospia labels DPDP Act 2023 compliance as by design, with a consent ledger consulted before use and personal data minimised and encrypted at rest. When the Interop module serves FHIR R4 reads such as Patient, Encounter or DiagnosticReport, the gate checks for a valid data-sharing consent first.
• Bounded automation: an AI agent in Ospia can never act outside the task registry or above the autonomy level the hospital configured. Execution above level L2 requires a named human, and L4 execution requires a policy the hospital approved. The starting autonomy for each agent is raised or lowered by the hospital as an audited decision.
• Data stays where you choose: each hospital chooses residency — self-hosted on its own infrastructure or managed cloud in-region — and sensitive AI task classes can be routed to a private model. In Ospia’s cross-hospital learning model, only the shape of a configuration can travel, never patient data or commercial terms, and it is contractual and opt-in.

Under the hood, Ospia’s agent memory model uses typed stores — session, conversation, user preference, patient context, hospital operational and long-term learned parameters — each with a retention and access policy. That makes it practical to implement the retention and minimisation rules your hospital sets.

A plain reading for executives

You do not need to become a privacy lawyer. You need to be able to ask for evidence that three things are true on any day: permission was checked before use, automation stayed inside boundaries you approved, and data lived where you said it should. If your current stack cannot show you that, change the operating model first, then the tooling.

If you want to see how these controls look in practice, ask for the executive demonstration. If you want to quantify the business case while you work through privacy controls, use the revenue leakage calculator. One reduces your risk. The other pays for the journey.

FAQ

• Can Ospia run without AI features turned on while we finalise our privacy posture?
  Yes. Ospia is a complete system with no external AI configured at all, using deterministic fallbacks for assistive paths, so AI is never a dependency for the hospital to keep running.
• How does Ospia prevent an agent from overstepping?
  Agents cannot act outside the task registry or above the autonomy level you set. Above L2 a named human is required, and L4 execution needs a hospital-approved policy. Autonomy settings are audited decisions you can adjust over time.
• What happens when another hospital uses a similar rule or workflow?
  Only the shape of a configuration — like a rule structure or workflow pattern — can travel, never patient data or commercial terms, and only if you opt in contractually.
• Can we keep data in-region or on our own infrastructure?
  Yes. You can choose self-hosted deployment on your infrastructure or a managed cloud in-region. Sensitive AI task classes can be routed to a private model.
• How are FHIR reads handled under privacy controls?
  Ospia’s Interop module exposes a FHIR R4 read surface gated behind a DPDP data-sharing consent check, so the permission gate is enforced before data is served.