Evora

Connecting a lab or device

Three levels, and none of them are negotiated privately

A lab does careful work and it often arrives as a PDF full of abbreviations. These are the three ways that work can reach a person's record instead. Each level is a step rather than a rebuild, each has requirements a person on our side reads, and each ends with a connection test against sample data — never a real person's result.

  1. Level 1

    Listed

    You appear on EVORA with what you offer, where you operate and how long results take. People still receive your result the way they do today, and upload it themselves.

    What arrives
    Whatever you already give the person — a PDF or a printout. They add it to their record, and it is read and normalised on our side.
    What it asks of the partner
    A signed agreement, a named contact, and a plain statement of any commercial relationship with EVORA. No engineering work at all.

    Requirements

    • A signed agreement is in place

      Covering what you may do with a person's data and what happens when the relationship ends.

    • A named contact who answers

      A person, not a shared inbox, we can reach when a result looks wrong.

    • Any commercial relationship is stated

      If EVORA earns anything when someone chooses you, it is written on your listing in plain words before anyone acts on it.

  2. Level 2

    File delivery

    You send results as structured files instead of PDFs. They land in the person's record already mapped, with units and reference ranges intact.

    What arrives
    One row per analyte: your own name for it, the value, the unit, the reference range you used, and the collection date. We map your names onto ours once, and reuse that map.
    What it asks of the partner
    A one-off mapping conversation, a sample file that passes, and a secure transfer route. No live endpoint to maintain.

    Requirements

    • Your analyte names are mapped to ours

      Done once, together, and written down. Anything we cannot map is kept exactly as you sent it and flagged — never guessed at.

    • Units are declared, not implied

      Every value carries its unit in the file, so nothing is inferred from the number's size.

    • Your reference ranges travel with the result

      Ranges differ between labs. Sending yours keeps a person's history honest when they move between you and someone else.

    • A sample file has passed the check

      Sample data only. We never test against a real person's result.

    • Transfer route agreed and tested

      Encrypted in transit, with a route we can both watch and revoke.

  3. Level 3

    Direct connection

    Results arrive as soon as they are ready. When someone's record suggests a panel and they order it from you, the result returns to the same record without anyone re-typing it.

    What arrives
    The same shape as file delivery, over a connection we watch. Nothing arrives without an order that person made.
    What it asks of the partner
    Documented endpoints, credentials you rotate, a person to call when it breaks, and a re-test whenever your format changes.

    Requirements

    • Endpoints and payloads documented

      Enough that a new engineer on either side can read it without a meeting.

    • Credentials are rotated on a stated schedule

      And can be revoked immediately by either side without a support ticket.

    • Failures are visible, not silent

      A result that fails to arrive raises something. A quiet gap in a person's record is worse than an error.

    • Someone answers when it breaks

      A named route with a stated response window, agreed in writing.

    • The connection test passed

      Against sample data, and again whenever your format changes.

Normalisation

What happens to a result once it arrives

Whichever level it came in on, every result is reduced to the same shape so a person's history stays comparable across labs and years. Nothing you sent is thrown away to get there.

Your name for the analyte
Kept verbatim, always, so the original is never lost.
Our canonical name and key
Mapped from yours once. Unmapped analytes are stored and flagged, not discarded and not guessed.
Value and unit
Both required. A value without a unit is held back rather than assumed.
Reference range used
Yours, not a generic one, so a change of lab does not look like a change of health.
Collection date
The date the sample was taken, not the date you sent it.
Where it came from
Your name sits on the reading in the person's record, permanently.
  • We never overwrite what you sent. Normalisation adds a canonical name beside your own; the original stays readable years later.
  • We never invent a unit, a range or a date. Anything missing is flagged for a person to resolve rather than filled in.
  • An analyte we cannot map is still stored and still shown to the person, marked as unmapped, until the mapping is added.
  • Normalisation does not interpret. A reading, with its citation, is written separately and can be read on its own.

Placement

How partners are ordered, and what we earn

The same rule as the clinician directory: written down, applied the same way for everyone, and never adjusted by hand.

  1. Partners connected at a deeper level come first, because a result that arrives already mapped is worth more to the person than one they re-type.
  2. Then whether they are working today rather than paused.
  3. Then how many places they serve, so the list is useful where you are.
  4. Then alphabetically. Position is never for sale and EVORA does not reorder it by hand.

Where EVORA earns something when you choose a partner, that is stated on the partner's own listing, in plain words, on the same screen as the choice. No partner can pay to appear higher, and being connected is never access — a person still creates every share.

You can read the connected partners at the partner list, or apply at the partner application.