# Do we need an Open Health Technology Foundation?
**Category:** [open forum](https://openhealthhub.org/c/open-forum/9)
**Created:** 2026-07-10 10:19 UTC
**Views:** 303
**Replies:** 24
**URL:** https://openhealthhub.org/t/do-we-need-an-open-health-technology-foundation/3025
---
## Post #1 by @pacharanero
Continuing the discussion from https://openhealthhub.org/t/meet-up-in-house-open-source-tools-for-the-nhs-28-05-26-1830/2991/8
This month I’ve been pondering whether we perhaps need some kind of ‘Open Health Technology Foundation’ that could offer support (practical and pastoral) to those like us, that are interested in open source health tech, and could also house projects that need an internet home. I have a number of projects that will proabably need this kind of ‘independent foundation home’, so I may well set up something like this.
I’'d be interested to get the views of this community on how such a foundation would work and whether you would be likely to join/become a supporter.
My initial sketch of the idea would be to set it up as a UK CIC (Community Interest Company), which is a low-admin, high-trust business vehicle that avoids the overhead of being a Charity. I’ve run 2 CICs before, so I know the area. It would aim to be more about building and doing, than a talking shop that writes Strategies, Reports, and other waffle that would be ignored anyway.
---
## Post #2 by @spdegabrielle
[quote="pacharanero, post:8, topic:2991"]
Open Health Technology Foundation?
[/quote]
I was thinking something like the [FSF](https://www.fsf.org/) or the Software Freedom Conservancy, which is a charity in the US, and amongst other things lets member projects accept donations as a charity.
I say this because I have donated to projects, but not the SFC in the past, despite their admirable mission.
> It would aim to be more about building and doing, than a talking shop that writes Strategies, Reports, and other waffle that would be ignored anyway.
Beyond the building and doing I feel there is a need for some guidance so providers can understand how they can use open source while meeting their obligations to patients and staff, but also procurement (Maybe this exists already).
What are the costs? / What are the benefits? / how can they use a project with their existing staff?
Even large trust rarely have in-house programmers - and those that do have 100% of their time already allocated. Most have system administrators and maybe a professional DB engineer if they are lucky.
(@mods should this be a new ‘topic?)
---
## Post #3 by @dalmolin
Hello from across the pond Marcus,
You may remember me from NHS England's venture into open source back in 2014-15. The CIC model is what I and Colin Smith proposed NHS England adopt....and I believe that's what Apperta is/was?
Still feel it's a great option for use cases like the one you describe...a couple of provinces in Canada have created the option of this class of corporation (we have both provincial and federal paths to incorporation).
Cheers,
Joseph Dal Molin
p.s. would love to connect and catchup when you have some time
---
## Post #4 by @pacharanero
[quote="dalmolin, post:3, topic:3025"]
You may remember me from NHS England’s venture into open source back in 2014-15. The CIC model is what I and Colin Smith proposed NHS England adopt…and I believe that’s what Apperta is/was?
[/quote]
Absolutely I do remember you - feels like a long time ago now, that NHSE were pushing for more open source. You may have seen that they recently [abandoned OSS entirely](https://shkspr.mobi/blog/2026/05/nhs-goes-to-war-against-open-source/).
Apperta was and still is a CIC, but sadly they seem to be a pretty much spent force now. They sucked up all the NHS Open Source 'oxygen' when they bust onto the scene, and then - well they did nothing much with it. At peak they managed to get hold of £500k of NHSE money, man what I could have achieved with that would have been a lot more effectual than what they did with it - committees and directors and boards and ceremony.
---
## Post #5 by @pacharanero
[quote="spdegabrielle, post:2, topic:3025"]
(@mods should this be a new ‘topic?)
[/quote]
I've left my post where it was because it did contain a response to the 'meetup', but I've copied the bit about an OHTF into this new topic and moved the replies.
---
## Post #6 by @jezmccole
*First post {gulp.today}*
:grinning_face: :+1: I would be interested in exploring / supporting something like this.
There are quite a few clinicians and small teams building useful open tools around clinical systems, data, workflow and decision support, but the difficult part is often everything around the code - governance, assurance, hosting, maintainership, succession and finding a credible route into NHS use.
A lightweight foundation could provide some of that shared scaffolding without taking ownership away from individual projects. The practical support would matter, but so would the pastoral side. Much of this work is done by individuals alongside demanding clinical roles, and it can be quite isolating.
A CIC sounds like a sensible starting point, provided it remains focused on helping people build, maintain and deploy useful things rather than becoming another strategy-producing body.
I would be interested in joining the discussion and contributing from the perspective of a GP who develops tools both standalone and across existing and emerging clinical systems.
Jez
---
## Post #7 by @shahbanaras
Hi all, I recently joined openhealthhub after stumbling across it whilst browsing an NHS github repo.
I’m not a GP, but a clinical pharmacist by background. Over the last five years or so, I’ve gradually moved into informatics and technology work and like a lot of people here by the sound of it, discovered I enjoy it far more than the traditional clinical role, pharmacy in my case.
Along the way I’ve taught myself Python, SQL, web development and a fair few other technologies. Most of what I’ve built so far has been a collection of small projects driven by my own ideas, partly to solve problems I’ve come across and partly to keep learning.
The discussion around setting up a CIC sounds really interesting. I’d be very keen to get involved if there is room for a non-GP colleague.
---
## Post #8 by @olizilla
Yes. I agree a CIC is a good vehicle, and I would be interested to join.
---
## Post #9 by @matthew.stibbs
In principle sounds like an interesting idea. I'd be interested in joining / supporting - pending a bit more understanding about what that would mean in practice!
---
## Post #10 by @Epicurean-Vegetarian
A CIC is a very good way. INTEROPen is a CIC and we survive on fresh air (apologies @ian )
---
## Post #11 by @dalmolin
It certainly feels like a long time ago...there was quite a bit of momentum, sad that Apperta didn't have the DNA to be able to channel it effectively. Not the first false start :frowning: , here's a link to the Open Source Health Care Alliance meeting...the first significant gathering of open source community of practice that I'm aware of, hosted by NHSE in London 2001:
https://web.archive.org/web/20011031095137/http://www.oshca.org/oshca2001.html
---
## Post #12 by @pacharanero
Thanks all for the support for the idea and for offering to join/support the CIC.
I think it's something that will be needed, as we've seen a few other approaches try and fail - for example the centralised NHSE Open Source Programme, becoming Apperta, then fizzling out...
We also have the global orgs all missing the point of grassroots healthcare innovation and ending up driven by their funders - see this recent announcement from Linux Foundation (it's a Google stackdump):
https://www.linuxfoundation.org/press/linux-foundation-announces-intent-to-launch-open-health-stack-software-foundation-to-advance-open-source-digital-health-innovation
@dalmolin the event you shared looks incredible - it's very much apparent how much health tech has changed in 25 years - how many clinicians were on that agenda (vast majority, experts, enthusiasts) compared to how many would be on the agenda at a health tech conference nowadays (only the ones that are the MD at a big company)
In terms of what the CIC would look like, here are some things I know:
* A CIC is fairly cheap to set up (£150 or so)
* Running costs are mainly accountancy fees (around £2k a year based on my other companies)
* It functions legally as a UK Company Limited By Guarantee.
* It must have a minimum of 3 directors
* It cannot have shareholders and therefore is resistant to being 'sold off'.
* There are rules about defining your community (the global open source health technology community)
* There are rules about what happens if you wind it up with assets (gift them to some similar entity)
In terms of the actual functioning of the foundation, I would propose: (all negotiable ideas)
* People who want to join would pay a fee (say £500?) each year which would initially just go into a bank account and give us some resources to get stuff done. We might have other tiers, higher and lower, but these do not confer different status in the organisation.
* Anyone with £500 and a will to join can join. There is no hierarchy of clinicians vs technical people vs patients vs other health tech professionals in terms of ability to join.
* Nobody gets in for free, however skilled they think they are, or whatever other benefit they say they are bringing to the table.
* The organisation should function as a[ do-ocracy](https://communitywiki.org/wiki/DoOcracy) so that small groups of motivated individuals can develop their projects under the aegis of the OHTF, without encountering bureaucracy and friction.
* We have a very lean decision making team around the business decisions, with the default answer being a qualified 'yes' unless the decision would be difficult to reverse.
* Committees are not permitted, they always end up as a talking shop and an accountability sink.
* Projects form around **code**, this can be a 'new-build' OHTF idea or an adoption of an existing project.
* We develop a 'house-style' for projects so that they are consistently high quality, safe, and well documented. (Essentially this is a repo full of instructions readable by humans and LLMs)
* The benefits of membership are what you make them.
---
## Post #13 by @DavidStables
If we are establishing another CIC, as opposed to being a member of the Linnux Open Health Stack Software, then we need to be clearer as how the foundation results in benefit to health, and how the CIC enables that. For example OHS is focusing on components for use inside applications and specifically excludes finished applications.
Having established a charity whose output is open source and 2 CICs whose output is nearly all open source, I have learnt many lessons, or more precisely, made many mistakes and its very easy to waste time going down a blind alley.
The value of this open health foundation may be in the collective health expertise being used to create the design for decent solutions rather than the open source lines of code, as the code agents make actual code redundant?. These days code is nothing more than either the description of the logic that is inherent in a design, or generates the visual representation which is the UI design. There is no longer IP in code, only in the detailed idea behind it.
We see in the market place the emergence of collaborations of competitors with shared interest to go up against the acquisition based companies, or the "big system" companies, so they could be beneficiaries of the outputs but that depends on what the outputs are.
Many initiatives of this kind (I co-founded HCIF in 2002 and Interopen in 2013) seem to rise and fall because they don't have a sustainability model, but if we can out the route to benefit, define the types of output, the nature of the route to market and the business model for sustainability I would join.
---
## Post #14 by @mayfield.g.kev
[quote="DavidStables, post:13, topic:3025"]
Many initiatives of this kind (I co-founded HCIF in 2002 and Interopen in 2013) seem to rise and fall because they don’t have a sustainability model
[/quote]
Agree.
A recurring question is how to create a sustainable interoperability model. Historically, NHS England funding has often been the primary driver behind initiatives such as InterOpen, but that approach has limitations. NHS Trusts generally have little discretionary funding to invest in interoperability on their own, making it difficult to sustain community-led standards once central funding ends.
In the longer term, the ecosystem would benefit from a model that is not wholly dependent on NHS England. While national programmes are important, they do not always address the day-to-day interoperability needs at organisational and regional levels.
One possible approach is greater collaboration between suppliers. Rather than waiting for centrally funded programmes, suppliers could work together to implement common interoperability standards—for example, Patient Care Coordination (PCC). If multiple suppliers supported the same standards out of the box, NHS organisations and social care providers would naturally be more inclined to select those products because of their genuine "plug-and-play" interoperability.
This is not a new concept. Patient Care Coordination standards were successfully demonstrated at several InterOpen Connectathons, particularly through the IHE Dynamic Care Planning profile. The technical feasibility was proven in a UK setting; what was missing was sustained organisational and commercial backing.
A similar story applies to the IHE QEDm profile, which was implemented in England under the Care Connect API programme. The capability was successfully tested and deployed in regions including Yorkshire & Humber and Wessex before the programme lost momentum. However, there is every indication that this type of capability will re-emerge as part of NHS England's Single Patient Record programme. Meanwhile, several major US electronic patient record (EPR) suppliers now include comparable patient care coordination capabilities as part of their standard product offerings, demonstrating that these standards can become commercially sustainable when embedded into core platforms.
---
## Post #15 by @dgm3333
It sounds sensible, but from my experience must of the NHS offers essentially no support - and many ditigal teams and others put a massive amount of effort into blocking such development. I can't even count the number of amazing projects I've seen over the years which have died under such persistent obstruction. I'm afraid after nearly 20 years of personally creating software which was given free for use in the NHS, including components which digitised the work of an hour every day of my role as an SHO 20 years ago to my current General Practice global system. I've had to fight against NHS managers every step of the way, and with digital teams who consider it their job to waste 10s of thousands of pounds every year (eg our local digital team disabled the touchsceen in all the practices as they said it wasn't core GP and they wouldn't support it). And the won't lift a finger to support innovation - it took 6 months to just get our practice DTAC signed off and they asked us only months later if we even had one. That along with and a central team which thinks spending 10s of millions annually on a 30year old SMS tech startup is a good investment when the NHS App doesn't even support notifications is clearly so far behind the times I think supporting open source is too much of a stretch for it.
But them I'm basically preparing to walk away from the NHS so consider me biased.
---
## Post #16 by @DavidStables
Also agree.
On the history of supplier collaborations HCIF (healthcare interoperability forum in 2002) was a supplier collaborative of about 10 suppliers, resulted in various CEN-TC251 schemas e.g. for online test ordering, and discharge letters, still in use today. It was closed down by npfit, as they wanted "ruthless standardisation" by which they meant their way. Interopen started as a supplier collaboration but included NHS Digital. The suppliers didn't at the time feel they had the business model to take this on beyond hackathons. It was also in the interests of the large suppliers to resist. NHS digital took the initial FHIR profiles we produced (DSTU2 Care Connect extensions , funded by a charity ) and became GP Connect (funded by NHS Digital). Interopen hasn't really gone anywhere since.
But is it now different ? I detect strong support for the idea of a collaboration from several SMEs and some internationals, but non at all from the large incumbents. Why would they, when all they have to do is wait whilst the small players show what they can do, then either wait for the fad to pass, copy in house if it works, respond to the tenders issued by the NHS to do something else, , or buy them to close them down. Plenty of evidence to support that strategy.
There is no appetite for another "interop" forum as the only thing that matters is delivery. But several do support the idea of a common data and comms platform (which is in effect any number of their own platform instances connected by common APIs).To make it work the platform has to support distributed query (population as well as patient level) and a Canonical logical data model to exchange definitions so able to map to their own schemas.
In supplier discussions, open source doesn't register and they still take the view that the value of their solutions reside in the IP and that includes the UI and business code that gives them the competitive edge. I see no change in this.
This is my challenge. In reality, does anyone on this hub wish to form a collaboration with each producing code components to a shared plan and shared design, and components are shared outside the collaboration as well?. I think that's the starting question from which the question of whether this is taken forward as a CIC or not comes from. I am a bit of a sceptic when it comes to the 3 forces that make up humans : Altruism, competitiveness, and greed.
---
## Post #17 by @dgm3333
I would be up for supporting a for-profit cooperative where everyone could support each others weaknesses with their strengths, but after I've seen how NHSE paid Palentir to stripmine the IP from lots of SMPs I wouldn't be willing to give IP away again - thinking they aren't planning to do it again is just idiocy.
TBH I'm just waitng for A/M/G to trigger even more AI price hikes and enshitification after the NHS takes all the knowledge and effort of SMEs pushing the digital and AI envelope and wipes them out - so any collective support against that and I'm up for it.
---
## Post #18 by @mayfield.g.kev
Only a slight tangent but this might be relevant.
Quite a lot of what I learned about health informatics was in my very early days at EMIS in the 90's.
The first things I learned was:
- clinical coding (read code) + a little later classification of those codes
- drug codes
- what an Observation looked like (clinical + optional value) - believe this was based on early version of HL7 OBX (now called FHIR Observation)
- what a consultation looked like https://en.wikipedia.org/wiki/SOAP_note
Fast forward to today and some of those are still are at that level or just slightly more detailed, e.g. SOAP I believe is related to PRSB clinical headings. Often I find BA's + developers who don't have this background
Is order and report workflows - this has moved on from 300 baud orders I did in the 90's but that basic workflow appears to be poorly understood
---
## Post #19 by @mike.bainbridge
I'm in total agreement David And Kev...Just an amplification of what I'm hearing from you both is that the code these days is less important and can be achieved with "relative ease". The limitation is still the lack of professional agreement on the semantics which drive safe interoperability. I've written 2 national standards for how this might be achieved for Allergy / Intolerance and another one about how to safely present meds / demographic etc. information on screen. How many systems use even parts of them? Very few. I'm currently writing a paper about how a dm+d using system needs to be modified to use AMT - just don't get me started on RxNorm !
---
## Post #20 by @JW148
I am watching this thread with a mixture of interest and considerable weariness having over the years had a number of battles with the system.
@DavidStables [quote="DavidStables, post:16, topic:3025"] is setting an important challenge. Are we up for it - and if so, how do we make the effort sustainable?
"This is my challenge. In reality, does anyone on this hub wish to form a collaboration with each producing code components to a shared plan and shared design, and components are shared outside the collaboration as well?"
[/quote]
---
## Post #21 by @dgm3333
My position is that "relative ease" for anything but common or non-complex functionality currently means (for example) I had to spend 2 hours yesterday explicitly and repeatedly telling the agentic coder to exactly replicate the medical UI for the v6 file version or our practice monitoring platform despite my having previously implemented and perfected the v5 version over the last year so it had existing examples to follow. The two hourse were spent to double-checking and repeatedly pointing out that it had implemented absolutely nothing the same as the previous version (including randomly changing the patient selection criteria !?!) - for which it apologised profusely but only made the modifications with explicit identification and repeated explanation of what it had still done wrong every loop (and it would totally drop the ball if I gave it more than one at once). And this despite me having explicit specifications, deterministic evaluation scripts, and screen based checking. Agentic coders remain unreliable for implementation of complex functionality unless you have a human double-checking absolutely everything. Thus if you are doing anything which requires complexity, reliability, or highly specified operation (eg most clinical tools), they still have a long way to go. This is probably marginally better than 12 months ago, but is definitely not the orders-of-magnitude improvement I had expected over the past 12 months. And this is essentially the same whether I'm coding C++, Python, or a React Native app. For every 2 hours of agentic coding I have found it needs at least as much time running deterministic tests and then another hour of testing to ensure it does what the task/contract it was given explicity stated. And if you don't watch it much of the time it's coding it has a high chance of going off piste...
So to rewrite that component from scratch would likely have taken me 10 hours to handroll - but it still isn't a negligible investment of time and expertise.
Similarly with a running coach app I've written for my phone - theres about a 30% chance that any new feature will result in it breaking some existing feature - and even with emulation and automation on a real phone running literally hours of simulated runs, problems still slip through and only become apparent during the live human-tested run.
---
## Post #22 by @ian
> Anyone had a look at https://dhcf.eu/
>
> DHCF envisions an ecosystem where digital health ‘just works,’ allowing time and resources to be invested in patient-professional relationships and technological advancements. We support “custodians” who develop sustainable solutions, in alignment with European digitilisation standards and values.
---
## Post #23 by @stephen
[quote="ian, post:22, topic:3025"]
We support “custodians” who develop sustainable solutions, in alignment with European digitilisation standards and values.
[/quote]
I couldn't identify any *custodians* or related projects?
---
## Post #24 by @mayfield.g.kev
My experience around health is this:
Although that is focused on semantic models, similar occurs around workflow (the clinical pathways are 'hidden') and also the core models. I think the main problem here is focusing on the data rather than the engineering (which is often focused on pathway) - it's the engineering side that tends to become black ops.
Software is a little better as some elements of the above are included but it is mostly aimed at a small group of clinicians or a narrow part of the pathway. These often don't scale up to work in an enterprise, core + semantic models are added as an after thought.
On both sides I feel more emphasis on process and then software+data is needed. The main org that takes this approach is IHE and it value is in early stages of development. The later stages can be handed off to other orgs such as openEHR, HL7, etc which go into more detail.
The general problem is lack of openness.
---
## Post #25 by @pacharanero
[quote="ian, post:22, topic:3025"]
Anyone had a look at https://dhcf.eu/
[/quote]
I hadn't heard of this, so thanks for sharing. However looking at their website it looks like **the website is all they have** (apart from a series of chats with practically everyone who attended EHRCON24...)
I am proposing a CIC that would look after the code. It would be run by its members and membership would buy you into the running of the org. The primary membership benefit would be the legal indemnity / liability protection afforded by having open source work owned by OHTF, not by an individual.
It won't be an idea all of you will like. I'm fine with that. It will be 100% open source and no exceptions, for example. But I think this model has potential.
Happy to discuss the idea back and forth here, but can we please keep the discussion about the subject of the OP - **"Do we need an Open Health Technology Foundation?"** not about the actual *details* of semantic modelling, agentic coding, or standards - they are all things that absolutely *should* be discussed, but please create new threads for them.
---
**Canonical:** https://openhealthhub.org/t/do-we-need-an-open-health-technology-foundation/3025
**Original content:** https://openhealthhub.org/t/do-we-need-an-open-health-technology-foundation/3025