Veona Records Requests

What this is

Veona Records Requests is the Release of Information (ROI) surface — the place a facility handles a request for a copy of a patient’s health record and discloses it through a controlled, audited workflow. Two doors lead into the same workflow:

a patient asking for their own records from the patient portal (their right of access), and
a third party — a lawyer, insurer, employer, court or another facility — whose request arrives by email, phone, post or in person and is logged at the front desk by a records officer.

Either way the request runs the same lifecycle: a records officer reviews it, decides per record category, fulfils it by compiling the approved record into a single encrypted pack, then discloses and delivers that pack — writing an immutable disclosure row that is the facility’s compliance trail.

Key terms used on this page:

Release of Information (ROI) — the regulated process of giving out a copy of a patient’s health record, to the patient or to an authorised third party.
Requester type — who is asking: Patient (the data subject), Authorized Representative, Lawyer, Insurer, Employer, Court or Other Facility. Everyone except the patient is a third party.
Records category — the kind of record a request is scoped to: Encounters, Clinical Notes, Diagnoses, Problems, Lab Results, Imaging Reports, Prescriptions, Vitals and Documents. A request names one or more.
Longitudinal compiler — the engine that gathers the approved categories for a patient across a date window and assembles them into a single branded Medical Records Pack PDF (a cover page with a contents index, then a chronological section per category).
Disclosure — one release of a record to a requester. Recording it is the accounting of disclosures.
Accounting of disclosures — the immutable Disclosure Log: an append-only record of who received what, over which date range, by which delivery method, and when.
Records officer — the non-clinical staff role that runs the whole ROI lifecycle end to end.

Who uses it

ROI access is least-privilege and deny-by-default. The lifecycle capabilities are:

View — see the request queue, a request’s detail, and the disclosure log.
Review — intake / assign a request, and make the approve / partially-approve / deny decision per category.
Fulfil — run the longitudinal compiler and store the encrypted Medical Records Pack.
Disclose — deliver a fulfilled pack (portal share or printed pickup) and write the immutable disclosure row.
Settings — maintain the per-facility settings (the optional copying fee, off by default).

The roles:

Records officer — a dedicated, non-clinical base-capability role that holds the full ROI lifecycle: view, review, fulfil, disclose and settings. This is the persona that runs release of information end to end.
Administrator — holds every ROI capability (the super-role).
No clinical role (and no front-desk role) is granted any records-disclosure capability. Records access is a deliberate, least-privilege capability — not a clinician or receptionist default. In practice, the person logging a third-party request at the front desk is a records officer, not the general reception role.
The patient reaches their own slice through the patient portal — they can only ever raise and read their own request and download their own delivered pack.

Editions

Records Requests / ROI is an always-on base capability — a patient’s right of access. It is not a sellable module and carries no SKU: the staff workflow is never licence-gated and is governed by records-disclosure permissions only. There is no edition that switches it off.

The one entitlement seam is the patient self-service door: the portal Records surface requires the Portal module. A facility without the portal can still run the full staff workflow and log requests on a patient’s behalf — patients simply can’t self-serve. (The staff rail entry sits under Admin and is shown to a records officer.)

Screens

The records-officer work surfaces (menu path Records → …):

Request Queue — every request with status, channel, requester, scope and fee; the entry point. A request’s full detail opens in a drawer when you click its row (there is no standalone “request detail” menu item).
Disclosure Log — the immutable accounting of disclosures, read-only.
Settings — the optional records-copying fee (off by default) and the default turnaround.

The patient sees a single Records area in the portal (menu path Records): a “Request my records” form plus a “My requests” status list with a download once a pack is delivered.

The request lifecycle

A request moves through these states:

Submitted — raised (by the patient from the portal, or logged by a records officer for a third party / non-portal channel).
Under Review — a records officer has been assigned (assigning a submitted request moves it here).
Approved / Partially Approved / Denied — the review decision. A partial approval names the subset of categories allowed; a denial requires a reason.
Fulfilled — the longitudinal compiler has run over the approved categories and the encrypted Medical Records Pack is stored.
Delivered — the pack has been shared to the patient portal or marked for printed pickup, and the disclosure row has been written.
Closed — terminal (alongside Denied and Delivered).

What the compiler assembles

When a request is fulfilled, the longitudinal compiler reads only the approved categories for the patient within the request’s date window and builds one branded PDF: a cover with patient identity, UHID, scope dates, a generated-at stamp and a contents index, then a chronological section for each category that has data — encounters, clinical notes, diagnoses, problem list, laboratory results, imaging reports, prescriptions, vital signs and on-file documents. The pack is stored encrypted at rest through the shared Storage module, owned by the patient, and marked PHI. It is delivered only through an authenticated download (portal) or as a physical pickup — it is never attached to a notification.

The accounting of disclosures

Delivering a fulfilled request writes one disclosure row recording the patient, the requester (type and name), the released categories, the scope window, the document count, the delivery method, who disclosed it and when. The ledger is append-only by design — the database grant for the application deliberately omits UPDATE/DELETE on the disclosure table, so the compliance record cannot be altered after the fact. Every lifecycle action is also written to the tamper-evident audit trail.

Caveats (honest state)

Authorization is captured, not interpreted. A third-party request requires an uploaded authorization file (proof of consent), which the records officer can view before deciding. Veona does not parse, validate or expiry-check that document — the officer judges it.
Scope/redaction is by category and date, not by line. A request is limited by the approved categories and the date window. There is no per-record or per-line redaction inside a category — if a category is approved, the in-range records in it are compiled whole.
Partial fulfilment is at the category level. Partial approval drops whole categories; it does not partially include records within an approved category.
The fee is optional and off by default. A patient’s own request is free; an optional copying fee for third-party or expedited requests can be enabled in Settings and captured through the existing Bill → GL seam (service code RECORDS-COPY).

Settings

Settings holds the per-facility records-request options. The copying fee is off by default — a patient’s own request is always free. When fees are enabled, set the third-party and expedited fee amounts in the Fee Amounts panel; leaving an amount blank falls back to the standard records-copy tariff price. Settings also sets the default turnaround.