Clinical decision support and patient records

The trust layer for AI agents inside clinical workflows and patient-records pipelines.

Two distinct verticals share the healthcare sector pack. Clinical decision support is the high-stakes path: agents propose prescriptions, suggest diagnoses, and flag imaging findings under human approval. Patient records is the administrative path: agents read records, schedule appointments, and run subject-access-request exports. The pack ships one policy template per vertical, regulator bindings for HIPAA, CQC, MHRA, and the Caldicott principles, and an integration brief per vertical so an engineer can read end to end without further authoring.

Which frameworks the healthcare pack maps to today.

Framework
Jurisdiction
Coverage
Notes
HIPAA Security Rule
vortalis_proxy/compliance/frameworks.py (build_hipaa_sections)
tests/conformance/regulators/hipaa/
US (45 CFR Part 164)
Full
Administrative safeguards, technical safeguards (access control, audit controls, integrity controls, authentication, transmission security), and documentation requirements are mapped to platform primitives. Physical safeguards are explicitly NOT_AVAILABLE_IN_PLATFORM because a runtime proxy cannot witness facility-access controls.
Caldicott principles
vortalis_proxy/middleware/caldicott_middleware.py
UK
Full
Per-tenant Caldicott posture lives in the middleware: profile-based access matrices, field-level filtering, patient opt-out, and per-tenant Caldicott Guardian configuration. Mapped to all seven Caldicott principles including principle 4 (strict need-to-know) and principle 7 (the duty to share for individual care).
GDPR (UK and EU)
vortalis_proxy/compliance/frameworks.py (build_gdpr_sections)
UK and EU
Full
Article 9 special-category healthcare provisions cover patient-identifiable data; the platform's tokenisation invariant plus the per-tenant audit chain feed the broader GDPR posture.
CQC Key Lines of Enquiry
vortalis_proxy/compliance/cqc.py
tests/conformance/regulators/cqc/
UK (England)
Partial
Safe, Effective, Responsive, and Well-led map to platform primitives. Caring is explicitly NOT_AVAILABLE_IN_PLATFORM because a runtime governance proxy cannot witness the direct experience of care.
MHRA Software as a Medical Device
vortalis_proxy/compliance/mhra.py
tests/conformance/regulators/mhra/
UK
Partial
Yellow Card audit-evidence support, clinical risk management (DCB0129 / DCB0160) where applicable, and post-market surveillance. AI/ML-specific lifecycle controls are explicitly anticipated; the section will be revisited when the MHRA publishes formal guidance.

Upstream services Vortalis adapts for this vertical.

  • NHS SpineShipping

    Adapter at vortalis_proxy/services/nhs_spine.py. Counterparty certification with NHS Digital is the operator's responsibility.

  • GP ConnectShipping

    Adapter at vortalis_proxy/services/gp_connect.py. Operator-side credentials drive the adapter; Vortalis does not certify the GP Connect endpoint.

  • IM1Shipping

    Adapter at vortalis_proxy/services/im1.py for the IM1 patient-facing-systems pairing API.

  • FHIR (HL7 R4 / UK Core)Shipping

    Adapter at vortalis_proxy/services/fhir.py. UK Core validation is opt-in via settings.uk_core_validation; validation warnings surface to the calling system without blocking the action.

The policy templates for this sector.

Clinical decision support with patient-records access

Actions allowed

10

Each action gated by policy at the hot path.

Anticipated require_human actions

  • prescription.proposed
  • prescription.approved
  • diagnosis.suggested
  • imaging.flagged

Rate-limit posture

Per-action caps on patient.record_accessed (200 in 24h), prescription.proposed (50 in 24h), and diagnosis.suggested (100 in 24h). Defensible defaults for a single-clinician engagement; multi-clinician deployments raise with explicit clinical-safety-officer agreement.

Template path: policies/sectors/healthcare/clinical-decision-support-template.yaml

Patient records access without clinical decision-making

Actions allowed

5

Each action gated by policy at the hot path.

Anticipated require_human actions

  • patient.record_exported

Rate-limit posture

Per-action caps on patient.record_accessed (300 in 24h), patient.record_exported (5 in 24h, intentionally tight), and patient.appointment_scheduled (100 in 24h). Bulk export is the highest-risk action a non-clinical agent can take.

Template path: policies/sectors/healthcare/patient-records-template.yaml

The implementation guide your engineers read first.

Clinical decision support with patient-records access

Available

docs/governance/integration-briefs/healthcare-clinical-decision-support.md

Patient records access without clinical decision-making

Available

docs/governance/integration-briefs/healthcare-patient-records.md

What this sector pack does not do.

Vortalis does not deliver clinical care; it governs AI-agent decisions that influence clinical care.

The platform records what the agent proposed, what the policy decided, and what the human approver did with the proposal. It does not deliver the care. The clinician's judgement, the bedside experience, and the patient's outcome are outside the platform's evidentiary reach; the CQC Caring KLOE is explicitly NOT_AVAILABLE_IN_PLATFORM because a runtime governance proxy cannot witness it.

Counterparty certification with NHS Spine, GP Connect, IM1, FHIR servers, and EHR vendors is the operator's responsibility.

Per the public limitations page, Vortalis ships adapters as code, not as counterparty-certified production integrations. The operator's existing credentials drive the upstream calls; NHS Digital's pairing, FHIR-server registration, and EHR-vendor contracts are the operator's path. Vortalis governs the agent's action at the boundary; it does not assume the counterparty obligation.

Patient-identifiable data tokenisation is a Vortalis primitive; the determination of which fields constitute PHI in a given jurisdiction is the operator's responsibility.

The tokenisation invariant covers patient names, NHS numbers, MRNs, dates of birth, addresses, and other identifiers the operator declares in the policy YAML's data_access block. The question of which fields constitute Protected Health Information under HIPAA, special-category personal data under GDPR Article 9, or patient-identifiable information under the Caldicott principles is a jurisdictional determination the operator's data-protection lead makes. The platform tokenises what the policy lists; it does not adjudicate the legal classification.

Caldicott posture is enforced per-tenant by middleware; the Caldicott Guardian identity and approval workflow lives in operator configuration, not in Vortalis.

The Caldicott enforcement code sits at vortalis_proxy/middleware/caldicott_middleware.py and runs on every healthcare-adapter request. The Caldicott Guardian is a named human role inside the NHS organisation; the platform does not adjudicate the Guardian's decisions. The per-tenant configuration accessor (get_caldicott_guardian_config) records the Guardian's identity and approval workflow so an audit reader can reconstruct who the named Guardian was at the time of any recorded access.

The general-purpose honest limits sit at /security/limitations; this list is specific to the healthcare pack.

Bring Vortalis to your healthcare agents.

Read the integration brief if you would rather start with the engineering detail. Talk to us first if you would rather start with a conversation about your threat model.