AI platform · Product 05 · In development
Clinical Intelligence
AI drafts. Doctors decide. A clinical operations platform where AI does the writing-up and the specialist reach extends past the building — while the medical decision, and the accountability for it, stays exactly where it belongs.
In active development. Not yet available for clinical use.
01 Primary workflow
From nurse intake to
doctor-approved note.
The documentation burden moves off the clinician and becomes a review step — without the record ever leaving clinical control.
- 01
Patient context
Staff register or select a patient, assign unit and bed, and open the relevant clinical episode or ICU context.
- 02
Nurse intake
Vitals, symptoms, assessments, attachments and bedside notes are captured on the mobile app, close to the patient and in structured form.
- 03
AI assistance
The platform organises that clinical data and prepares draft summaries, documentation support, abnormal-trend highlights and review prompts.
- 04
Doctor review
A doctor reviews the record, edits the AI-drafted content, approves or rejects it, and finalises the note or care-plan update.
- 05
Audit and handoff
Every critical action is logged append-only, routed to the right queue, visible to authorised teams and available for reporting.
02 AI governance
The AI writes.
It does not decide.
An AI that quietly edits a medical record is a liability, not a product. So the constraint is built into the data model rather than into a policy document: AI content is labelled, editable and traceable, and it cannot enter official documentation without a named clinician approving it.
A final note stores its author, its approver, the timestamps, the source data behind it and every edit along the way. Escalation suggestions stay advisory until an authorised clinician acts.
Governance rule
AI produces draft support only. The medical decision, the approval and the accountability remain with an authorised clinician.
Audit rule
Capture the prompt context, the generated draft reference, the clinician edits, the final approval, any rejection reason and the downstream handoff status.
Safety rule
Disclaimers, review states, permission checks, visible sources and escalation guardrails all sit in front of production use.
03 Remote care model
Specialist depth,
without losing ownership.
Most Indian hospitals cannot staff an intensivist around the clock. Tele-ICU extends that reach — but the local team keeps clinical ownership; the remote specialist advises, and the platform tracks whether that advice was accepted, modified or declined.
Case escalation
Staff flag a patient for specialist review on severity, abnormal vitals, unit protocol or manual escalation.
Remote specialist review
Specialists get structured patient context, recent trends, draft summaries, attachments and the consult question in one case view.
Recommendation capture
Recommendations are documented, routed back to the local doctor and marked accepted, modified, declined or pending clarification.
Operational oversight
Leaders monitor pending consults, response times, bottlenecks and handoff completeness.
04 Capabilities
What the platform does
AI-assisted documentation
AI drafts clinical summaries, progress notes, abnormal-trend highlights and handoff summaries from structured bedside data — turning the documentation burden into a review task rather than a writing task.
Doctor approval built in
Every draft lands in an approval queue. A doctor can edit, accept, reject, request clarification, or mark an output as not clinically useful. Nothing reaches the record unapproved.
Tele-ICU and specialist review
Bedside teams escalate a case; remote specialists see structured context, recent trends and the consult question in one view, and their recommendation is routed back and tracked to closure.
Traceable by design
Each final note stores its author, approver, timestamps, the source data behind it, the clinician's edits and the full audit trail. AI content is visibly labelled and never silently merged in.
Speaks the hospital's language
HL7 FHIR R4 as the primary contract, with HL7 v2 and DICOMweb where that is what a site exposes — normalised at the boundary so core services see one model.
Tenant isolation throughout
Every patient record, workflow, session, audit event and report carries hospital scope. RBAC drives what a user sees, and the backend — never the interface — is the enforcement authority.
05 Architecture
Built to be
audited, not just shipped.
A modular platform where permissions, tenancy and audit are enforced in the backend — so a new clinical module inherits the guarantees instead of re-implementing them.
Why this runs in the cloud
Hospitals cannot each host an AI platform, and clinical data cannot sit on a single box. The workload needs managed Postgres with point-in-time recovery, isolated environments for development, QA, staging and production, GPU-backed inference for summarisation, object storage for attachments, a managed KMS for per-tenant key scoping, and an observability stack that can prove what happened during an incident.
It also needs to run in a region under a provider BAA, with selectable data residency — which is a cloud decision before it is an engineering one.
06 Interoperability
HL7 FHIR R4 is
the contract.
Everything else is normalised at the boundary, so core services only ever see one model — and a hospital is never asked to change its systems to adopt ours.
Hospital systems
- FHIR R4 Patient, Encounter, Condition, Observation, DocumentReference
- HL7 v2 ADT where a site has no FHIR endpoint
- C-CDA and IHE XDS.b for discharge summaries and referrals
Diagnostics and imaging
- FHIR ServiceRequest / DiagnosticReport, or HL7 v2 ORM/ORU over MLLP
- DICOMweb (WADO-RS, QIDO-RS, STOW-RS) and FHIR ImagingStudy
- No image copies stored by default
Devices and bulk data
- Nurse-entered vitals first; device feeds mapped to FHIR Observation with LOINC codes
- CSV and FHIR Bulk Data ($export, NDJSON) for sites without real-time integration
- Streaming device data only after safety, scale and alert-ownership sign-off
Identity and terminology
- OIDC and SAML 2.0 SSO, MFA, and SMART on FHIR app launch
- SNOMED CT, LOINC, ICD-10/11, RxNorm and CPT mapped per site
- Regional profiles plug in at the integration layer, not in core services
HL7 FHIR R4US Core / IPSSMART on FHIRHL7 v2.xC-CDADICOMwebIHE PIX/PDQ, XDS.b, ATNASNOMED CTLOINCICD-10
07 Security and compliance
Least privilege,
isolation, evidence.
HIPAA first, with GDPR and ISO controls built into the same platform rather than bolted on for an audit.
Identity and sessions
OAuth2/OIDC, short-lived access tokens, rotating refresh tokens, secure mobile token storage, MFA-ready admin access and forced logout on risk events.
Tenant isolation
Every user, patient workflow, audit event, session, role, report and configuration record is scoped to its hospital, region or unit.
Data protection
TLS 1.2+ in transit and AES-256 at rest across database, object storage, backups and exports, with keys in a managed KMS and no ePHI in logs, traces or URLs.
Audit coverage
Login, access denial, user lifecycle, role change, session revocation, clinical approval, AI draft change and consultation actions are all append-only events.
HIPAA / HITECHGDPRISO/IEC 27001ISO/IEC 27701ISO/IEC 27799SOC 2 Type IIHITRUST CSFNIST 800-53OWASP ASVS L2
Certification status. The frameworks above are design targets and control commitments. SOC 2 Type II and HITRUST require an observation window and an external auditor and are scheduled work — nothing here should be read as a claim of current certification.
08 Questions
Frequently
asked.
In development. VEHA Clinical Intelligence is not available for clinical use and nothing on this page should be read as a claim of regulatory clearance or completed certification. The security and compliance frameworks listed are design targets and control commitments; audited certifications such as SOC 2 Type II and ISO 27001 require an observation window and an external auditor, and are scheduled work, not current status.
What is VEHA Clinical Intelligence?
An AI-assisted clinical operations platform for hospitals and specialist care teams, covering bedside intake, AI-drafted documentation held under doctor approval, and Tele-ICU specialist collaboration — across web and mobile.
Does the AI make clinical decisions?
No. The governing rule of the platform is that AI produces draft support only — the medical decision, the approval and the accountability remain with an authorised clinician. AI output is labelled, editable and traceable, and escalation suggestions stay advisory until a clinician acts on them.
Is it available today?
Not yet. Clinical Intelligence is in active development and is not available for clinical use. We are talking to hospitals interested in shaping it and in early pilot participation.
How does it connect to our existing hospital systems?
HL7 FHIR R4 is the primary integration contract, covering Patient, Encounter, Condition, Observation and DocumentReference. Where a site has no FHIR endpoint we accept HL7 v2 (ADT, ORU, ORM) through an interface engine, DICOMweb for imaging, and C-CDA for documents. Sites with no real-time integration can start with CSV or FHIR Bulk Data import.
What about patient data and compliance?
The platform is being designed to HIPAA and GDPR from the start: TLS 1.2+ in transit, AES-256 at rest, managed KMS key handling, per-tenant scoping, append-only audit, and no ePHI in logs, traces or URLs. These are design commitments — see the status note on this page for what is and is not certified today.
Who is it for?
Hospitals running ICUs and wards that carry a heavy documentation load, and specialist networks that want to extend intensivist coverage to sites that cannot staff it around the clock.
09 Get involved
Shape it before
it ships.
We are looking for hospitals and ICU teams willing to pressure-test the workflow, and for clinical and engineering partners who want a say in how AI enters the medical record. Early pilot conversations are open now.