Skip to content

Drive Every Picker From Typed Reference Data

Look closely at the dropdowns in Veona and you’ll notice they are not little hard-coded lists baked into each screen. Wherever a field points at real data in your facility — a department, a ward, a bed, a clinician, a service point, a location — the picker is a searchable combobox fed live from your facility’s own reference data. Add a department in admin and it appears in every dropdown that uses departments; rename it and it updates everywhere. Nothing is typed twice, and no screen carries a list that has drifted out of date. This page explains the pattern and how the reference data behind it is maintained.

Who / when: every role uses these pickers, all day — choosing a ward at admission, a provider on a referral, a service at the desk. A Tenant Admin (or the relevant manager) is the one who maintains the reference data the pickers draw from.

The words you’ll meet:

  • Reference data — your facility’s own master lists: departments, locations, wards, beds, service points, providers, and the like. It is data, managed in one place, not options frozen into code.
  • Picker / combobox — the type-ahead dropdown you use to choose one of those things. You start typing, it searches, you pick a match.
  • Typed-FK (foreign key) — the field stores a reference to a real record, not loose free text. Picking “Maternity Ward” links to that exact ward, so the data stays consistent and connected.
  • Searchable — the list is fetched and filtered as you type, so even a long catalogue (thousands of drugs or tests) stays fast and you never scroll a giant menu.
  1. Any role — when a screen needs you to choose something that exists in your facility — a ward on the admission form, a clinician on a referral, a department on a staff profile — you get a searchable combobox: start typing, and Veona returns matching records from the live reference data for you to pick.
  2. Any role — what you can pick is always current. There is no separate “list of options” maintained per screen that could fall behind; every picker reads the same shared reference data, so a record added or renamed in admin shows up the moment you next open the dropdown.
  3. Tenant Admin — to maintain the lists the pickers draw from, open the relevant admin surface: Admin → Departments for departments, Admin → Facility for the facility’s locations and structure, and the per-module setup screens for things like wards, beds and service points. What you create there is exactly what the pickers offer.
  4. Tenant Admin — when you add a new reference record, it becomes selectable straight away in every combobox that uses that resource — no code change, no waiting for a release, no editing each screen. Add a clinic location once and every “location” dropdown across the product can choose it.

What happens next: because every picker is driven from one managed source, your facility’s data stays joined-up and trustworthy — a department chosen on a chart is the same department reported on in analytics, billed against, and audited. Set the reference data up once and it powers ordering screens, registration, scheduling and clinical forms alike, all reading from the same place, all current. It is the quiet reason the rest of Veona’s records line up.