Veona Group — Network & Master Patient Index

What this is

Veona Group is the multi-facility surface. When an organisation runs more than one facility — a hospital with satellite clinics, or a chain — Group ties them into a network: it recognises when the same person is registered at different sites, lets a clinician (with consent) see that patient’s records held elsewhere, and rolls the whole network up into one consolidated report. It does this without merging the facilities’ books or breaking each site’s data isolation — every cross-facility read is deliberate and audited.

Key terms used on this page:

• Network (facility group) — the set of facilities operated as one organisation, with a shared policy.
• MPI (Master Patient Index) — the index that links the records of the same real person registered separately at different facilities, under one master patient identity.
• Candidate — a probable-match pair the system surfaces for a human to confirm or dismiss (e.g. same name + date of birth + phone at two sites). Matching never auto-merges below the steward’s review.
• Steward — the person who reviews MPI candidates and decides to link, reject, or unlink them.
• Break-glass cross-read — a clinician’s deliberate, consented, fully-audited read of a patient’s record held at another facility in the network.
• Consolidated report — a network-wide roll-up that is PHI-free (counts and totals only, never patient identifiers).

Who uses it

Roles below are the canonical group roles; the surface is restricted to elevated roles.

• Group Administrator — manages the network and its policy (how aggressively the MPI matches, whether cross-facility reads need break-glass), acts as the MPI steward, reads the consolidated report, and may perform a cross-facility read. The full surface.
• MPI Steward — reviews MPI candidates and links / unlinks them, with read access — but no policy control. A focused data-quality role.
• Clinician — does not manage the network, but can use the cross-facility linked records affordance on a patient’s chart (consent + break-glass) to read that patient’s notes from another site.

An Administrator can do everything in the module.

Editions

Veona Group is the paid Group module. It is included in the Network and Veona Enterprise editions. A standalone (single-facility) deployment has no network — the group screens report “not in a group”, and cross-facility access is unavailable.

Screens

The Veona Group work surfaces:

• Network — the facilities in the group and the network policy (MPI matching + cross-facility access rules). Group-admin only.
• Patient Index (MPI) — the steward’s review queue: pending candidate pairs to link or reject, and the master patients already linked (with their member records per facility) to unlink if a match was wrong.
• Consolidated Report — the PHI-free network roll-up across all facilities.

How the Master Patient Index works

1. As patients are registered at each facility, Veona compares new registrations across the network and surfaces likely same-person matches as candidates — it never silently merges records.
2. The MPI Steward opens Group → Patient Index (MPI) and reviews each candidate pair. They Link a genuine match (the two records now share one master patient identity) or Reject a false one. A wrongly-linked member can be Unlinked later.
3. Once linked, a clinician viewing that patient’s chart at one facility sees a linked records affordance — the same person has a record at another site. Reading it is a deliberate break-glass cross-read: it requires consent per the network policy and is written to the tamper-evident audit log (who read what, where, and when).

The network policy (Group → Network) controls how the index behaves — how confident a match must be before it becomes a candidate, and whether cross-facility reads require break-glass — so a cautious network can keep matching strict and access tightly gated.

Note

Cross-facility access is deny-by-default and audited. A facility’s data is never visible to another site unless the patient is linked in the MPI and a clinician performs a consented, logged break-glass read — there is no ambient cross-facility visibility.

Caution

Linking is a clinical-safety decision. Linking two different people would expose one patient’s record under another’s chart, and unlinking after the fact does not un-see what was read. Stewards should link only on a confident match (the candidate shows the matched identifiers), and the network policy should set the match threshold conservatively.

The network and its policy

Network (the Group Administrator’s screen) lists the facilities in the group — each as Primary or Member, with the date it joined — and governs how patient data is shared across them:

• Cross-Facility Patient Access — allow a clinician to open a linked patient’s records from another facility (consented and break-glass audited). Off by default.
• Require Patient Consent — the clinician must assert the patient consented at each cross-facility read.
• Surface MPI Matches for Review — proactively compute probable cross-facility matches at registration for the steward to confirm. Never auto-merged.
• Match Threshold — the minimum confidence (0–100) before a pair is surfaced for review.

Changes save as you set them. A facility that is not part of a group sees a “not in a group” screen instead.

What it connects to

• Register / Chart — the source of the patient records the MPI links and the cross-read surfaces.
• Audit — every cross-facility read and steward action is recorded (see the Foundations guides).
• Veona Pulse — network-level analytics build on the same consolidated, PHI-free data.