James Morgan

Twenty years of building a record system as a public asset, and why the hardest conversation is about who owns it.

Part of the OpenEyes Conference interview series, recorded on 16 September 2026 in Cardiff, UK.

Building a Public Asset: Twenty Years of Clinician-Led Development

If you've got visions of being a billionaire or a multimillionaire, then please just park them at the door. We're building a public asset.

About James Morgan

James Morgan is Professor of Ophthalmology at Cardiff University and, as he gives it, a director of the OpenEyes Foundation. He has worked on electronic patient records and imaging connectivity since the late 1990s.

Interview summary

He came to this from both sides, building electronic records and imaging connectivity from the late 1990s in research and clinical settings. A data system built out of frustration at not knowing what was happening in his own neuroscience lab led him to a short piece by Bill Aylward, then Chief Clinical Information Officer at Moorfields, describing what was at that point a couple of pages of HTML. Recognising the two applications were essentially the same, he joined forces with Aylward in 2010, deployed OpenEyes in Cardiff, and forked a Cardiff version. Colleagues from Moorfields came to ask how it was being done; he was later seconded there from 2014 to 2016 to develop the product.

The frustration he describes is specific and it is about waste. The NHS has people who could lead software companies and choose instead to treat patients, and there was no channel for what they knew other than letting it bleed into commercial entities for other people's benefit. He lists the pattern: a product built up and sold on, built up and sold on, until control is lost and the people running it are doing so for other purposes. The response was to build an asset for public benefit.

That carries one conversation he has with everyone who joins: anyone with visions of becoming a billionaire should park them at the door, because this is a public asset. He says it is the hardest thing to explain when deploying commercially - that they push the product and do not own it - and that approaches have been made to buy and fund it on venture capital terms. He is equally clear they are not hair-shirt about it: the deployment base means they can and must behave commercially, because governments and hospitals require firm contractual commitments.

What he regards as the real resource is unspent and off the balance sheet: the curiosity and wish to improve care among contributing clinicians, many with technical skills on a par with engineers and no time to use them. He credits the ethos of the NHS for it, and describes the difficulty of costing that kind of goodwill.

He is precise about where software projects fail. Writing a few lines that run in a browser is a hobby application, useful mainly as a way of thinking. Enthusiasm commonly fades at years two and three, which is when the work actually starts; deploying regulated clinical software in a government health system becomes hard at years four and five. Getting through that took intensive sprints and stubbornness, and the first test was pitching to deploy OpenEyes back into Moorfields - which required putting it under the foundation first, because the NHS was a poor place to develop software. Scotland, Wales and commercial providers followed the same pattern.

On intellectual property he describes the precedent that set the tone: Aylward developed a module, was approached to sell it, and signed the intellectual property over instead, signing off a substantial payment into the public register. Every feature since has gone the same way, and he says it is surprisingly not a difficult decision, because the people involved could have gone to work in the city and chose to be clinicians. The recompense he names is that they get to use the product in their own clinic, and can fix what does not work without negotiating with a finance director or an investor.

He is candid that the early hack days pushed in the wrong direction - inviting anyone who could code to contribute production code. The lesson was that a clinician writes a prototype and an engineer refactors it: ideas transmitted in code rather than code for deployment. The days also serve as talent spotting, which he likens to watching who can really play, and as teaching, with tutorials on clinical semantics and object-oriented thinking running in both directions between clinicians and engineers.

The funding mechanism he describes may be the most transferable thing in the interview. Five hospitals each wanting a fifty-thousand-pound change cannot coordinate a joint payment to a supplier - finance directors have no route to it. But each can commission the foundation for a subset, so the tickets are broken into chunks, the funding aggregated, and a developer commissioned to build something every site then has. He says they did this without planning it and only afterwards recognised it as crowdfunding inside a legitimate ordering system. Industry now funds development too, gaining visibility of how its products perform without data being sold.

His view of the future EPR is a series of domain-driven developments that plug into a common multi-layered environment, rather than the monolithic systems being deployed, which he dates to twenty or thirty years ago and which cannot deliver best-in-class solutions. The foundation's role, as he puts it, is to take the approach to other domains - orthopaedics, dermatology - and the code is almost irrelevant beside the culture and collaboration.

His wish is to use the data already in the system to show whether care is actually better. He describes the common trope that a busy clinic with a waiting list means a clinician must be doing something good, and says he has no evidence of it. He contrasts hospitals with large atria and car parks - temples of disease, pointing to an unhealthy population - with the question of which country is actually healthier, and wants the tools to look after populations rather than index cases. Healthcare, on his account, should be as undramatic and boring as possible.