Introduction to Ever network governance

What is governance?

Governance is the set of systems that lets decisions be made. In a company, a board or executive team may have the final say. In a country, elected representatives pass laws on behalf of the people they represent. In a hospital, committees decide on clinical policy.

Governance without a single owner

A health information network only works if every member trusts it. A hospital will not send its records through infrastructure that a competitor, a vendor or any single party can change at will. So the protocols that connect members (how records are exchanged, how consent is recorded, how identities are matched) need a change process that members can see, take part in and, if necessary, refuse.

This is about the protocols, not about who may use them. Within the rules a member has agreed to, any connected hospital can exchange records and any developer can build on the published interfaces. Governance decides how those rules and interfaces change, and because so many people depend on them, the bar for a change is high.

Private network today, global network tomorrow

Ever's exchange runs today as a private, permissioned network. Ever maintains the protocol implementations, operates the shared services and coordinates each release with the member organisations. That is the right shape while the network is young: members get one accountable party, and changes can be made quickly and safely.

The concept is designed to expand. The proposal process, the review stages and the rule that no member can be forced to upgrade are the same on both. What changes as the network grows is who sits at the table: more maintainers, more implementations, ministries and patient representatives alongside hospitals, until no single organisation, including Ever, can decide alone.

Offchain decisions, onchain records

Some networks govern themselves onchain: holders of a governance token vote, and an approved change can take effect automatically. Others govern offchain: changes are discussed in the open, agreed socially and then written in code.

Ever network governance happens offchain. There is no governance token and no coin vote, and health data is never something a vote can decide. The ledger is used for what it is good at: a tamper-evident record of consent, access and exchange events that every member can audit.

Who is involved?

Many groups take part, each with a different stake. Starting with those furthest from the protocol and moving closer:

1. 01PatientsThe people the records describe. They decide who reads their data, and every change is judged first by whether it keeps that promise.
2. 02Clinicians and application usersDoctors, nurses, pharmacists and staff who work in hospital systems connected to the network.
3. 03Application and tooling developersTeams who build on the network's interfaces (FHIR, HL7v2, event subscriptions) or build tools around them.
4. 04Hospitals and node operatorsHealth systems that run a node, keep their own data on their own hardware and choose when to take an upgrade.
5. 05Country-pack maintainersLocal experts who keep a country's language, codes, payer rules and forms correct.
6. 06Proposal authorsAnyone who writes a proposal to change a network protocol, and champions it through review.
7. 07ValidatorsMember organisations that run the permissioned ledger nodes which record consent and exchange events.
8. 08Core maintainersThe engineers who maintain the protocol implementations. Today this is Ever; the aim is for it to be many organisations.

One person can belong to several groups: a hospital engineer might run a node, author a proposal and maintain a country pack. Separating the roles simply makes it clearer whose interests a change touches.

What is a proposal?

Changes to the network are described in an improvement proposal: a short, public document that specifies a new feature or process, the reason for it, who it affects, and how it stays safe and private for patients. Any member of the community can write one.

Until the open proposal process is published, proposals are sent to Ever and reviewed with the members they affect. Write to us to start one.

The formal process

The formal route for changing a network protocol has five stages.

1. step 1

   Write a proposal

   Describe the change, why it is needed, who it affects and how it stays safe for patients. The proposal becomes the specification maintainers implement if it is accepted.

2. step 2

   Present it to the maintainers

   Bring the proposal, with the feedback you have already gathered, to a review with the core maintainers and the member organisations it touches.

   • →It is considered for a future network release
   • →Technical or clinical changes are requested
   • →It is declined, because it is not a priority or the benefit does not outweigh the work and risk

3. step 3

   Iterate towards a final proposal

   Address what reviewers raised (security, privacy, clinical safety, country differences) and present it again. New concerns may need another round.

4. step 4

   Include it in a network release

   Once accepted, implemented and tested, the change is scheduled into a release. Because every member node has to upgrade, changes are bundled together rather than shipped one by one.

5. step 5

   Activate the release

   The release runs on a test network first, then member nodes upgrade in an agreed window. After activation the change is live across the network.

This is a simplified view. It shows the main stages a change passes through before it is live; the informal factors below matter just as much.

The informal process

Understanding prior work

Before writing a proposal, read what has already been proposed, built or declined, so that yours brings something new and answers earlier objections. The roadmap and the documentation on evermedos.com are the places to start.

Working groups

A first draft is rarely adopted unchanged. Authors usually work with a few maintainers and with the hospitals and developers who will live with the change, to specify, implement, test and refine it. For larger changes this can take months.

Clinical safety review

Health data adds a review that general-purpose networks do not need. A change that alters what a clinician sees, what is recorded or who can read it is reviewed by clinicians as well as engineers, and by people who understand the privacy law of every country it touches. A technically sound change can still be declined if it is not clinically safe.

Community consensus

Some proposals are simple improvements. Others involve trade-offs that affect members differently, and those are contested. There is no single metric, such as a vote count, that settles them. No group can force another: maintainers can decline to implement, hospitals can decline to upgrade, and patients can withdraw consent. So changes whose contention outweighs their benefit are generally not made, and authors are expected to seek out objections and work through them.

Handling disagreements

With many members and many motivations, disagreement is normal. It is handled by open, written discussion that lets anyone affected weigh in. Usually one side concedes or a middle path is found.

Records are never rewritten

The network does not intervene in recorded history to settle a dispute. A mistaken record is corrected by appending a correction that points to the original, never by editing or deleting what was recorded. This keeps the network neutral and every member's audit trail trustworthy.

The utility of forking

Because the software is open source and every hospital keeps its own data, a member that disagrees strongly with the direction of the network can run its own network, or a country can run a national one, without losing its records. That freedom is part of what keeps governance honest: the network has to keep earning its members' participation.

How can I get involved?

• Propose a change
• Join the community of clinicians, engineers, researchers and patients
• Bring your organisation or country onto the network
• Build on the interfaces or self-host the stack
• Request source access to review or contribute to the implementations
• Follow the roadmap

Further reading

This page is modelled on the way the Ethereum community describes its own process, adapted for a health network:

• Introduction to Ethereum governance (ethereum.org)
• Notes on blockchain governance (Vitalik Buterin)
• Moving beyond coin voting governance (Vitalik Buterin)