# A team to develop, in house, open-source tools for the NHS **URL:** \ **Category:** open forum\ **Created:** [19 March 2026 09:30 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944 "2026-03-19T09:30:28Z")\ **Posts on this page:** 15\ **Page:** 3
**Author:** ![pacharanero](https://openhealthhub.org/user_avatar/openhealthhub.org/pacharanero/32/1117_2.png) [@pacharanero](https://openhealthhub.org/u/pacharanero)\ **Post date:** [14 May 2026 09:08 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/41 "2026-05-14T09:08:59Z")
Hi @james.roberts I didn’t have anything in my diary for today, and I’m unavailable I’m afraid. I’ll have a look through the documents you’ve shared and comment back here. ---
**Author:** ![olizilla](https://openhealthhub.org/user_avatar/openhealthhub.org/olizilla/32/1214_2.png) [@olizilla](https://openhealthhub.org/u/olizilla)\ **Post date:** [14 May 2026 18:46 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/42 "2026-05-14T18:46:23Z")
How doo! @james.roberts and I had a good call. I’m on board too! We talked about - openEHR and using it as a boost so you can let it handle the data schema while you focus more on the app UX, - tree shaped data structures, neo4j, and event sourcing architectures. - BCS - primary health care specialist group - A Blueprint for a Co-Produced Personal Health Record (CoPHR) Ecosystem - Apperta foundation - [https://apperta.org/assets/Apperta\_A\_Blueprint\_for\_a\_Co-produced\_Personal\_Health\_Record\_Ecosystem.pdf](https://apperta.org/assets/Apperta_A_Blueprint_for_a_Co-produced_Personal_Health_Record_Ecosystem.pdf) - Degradation of medical data as it passes between different EHRs - The knowledge-driven platform: Strategic technologies for a platform ecosystem approach [https://www.sciencedirect.com/science/chapter/edited-volume/pii/B9780128234136000069](https://www.sciencedirect.com/science/chapter/edited-volume/pii/B9780128234136000069) - Medicus - as more modern EHR competitor to EMIS and SystmOne …and keeping this regular to get some momentum! See you in 2 weeks for the next one! ---
**Author:** ![pacharanero](https://openhealthhub.org/user_avatar/openhealthhub.org/pacharanero/32/1117_2.png) [@pacharanero](https://openhealthhub.org/u/pacharanero)\ **Post date:** [18 May 2026 11:37 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/43 "2026-05-18T11:37:27Z")
Can we set up some kind of recurring invite so that people know about it? Sadly calendar invites is one thing that Discourse is just really **bad** at doing, [I have raised it as an issue with the Discourse people](https://meta.discourse.org/t/add-to-calendar-ics-ical-attachments-for-events-in-discourse-notification-emails/399329/6). ---
**Author:** ![olizilla](https://openhealthhub.org/user_avatar/openhealthhub.org/olizilla/32/1214_2.png) [@olizilla](https://openhealthhub.org/u/olizilla)\ **Post date:** [18 May 2026 13:58 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/44 "2026-05-18T13:58:37Z")
if it’s not too noisy, how about we manually make a new thread / top post that we can attach event info to for each call? that way we can insert some suggested direction for the next call and link back to the previous call and notes can be added about that call to the thread. manually doing ensures someone takes ownership of coordinating and promoting the next call, but its easy for someone else to step in later. ---
**Author:** ![james.roberts](https://openhealthhub.org/user_avatar/openhealthhub.org/james.roberts/32/1166_2.png) [@james.roberts](https://openhealthhub.org/u/james.roberts)\ **Post date:** [19 May 2026 11:56 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/45 "2026-05-19T11:56:01Z")
Great to meet you @olizilla and thank you for answering the call. Really good to see the shared enthusiasm and recognition of this being an important direction of travel for how we move to the next iterations of these systems. Agreed we need to set up a regular meeting. Fortnightly on thursday evenings 18:30-19:30 seems right at present. Happy for people to drop in when able. We can use @pacharanero Jitsi suggestion as this allows a persistent meeting room that people can save and use at other times on a regular link. I will set up a new post for the next meeting to make it easier for people to find - that way people can bring any ideas or discussion points prior to the meeting and might be helpful if they are unable to attend. The task I have set myself for the next meeting is to establish the fundamental requirements of an EHR for the various users - clinicians, patients, healthcare organisations. I will produce the draft paper and welcome collaboration, improvements and suggestions. Once this has been defined we can look at what ‘building blocks’ would allow a system to meet these requirements. Keen for any thoughts/suggestions. See you all soon! James ---
**Author:** ![Emma](https://openhealthhub.org/user_avatar/openhealthhub.org/emma/32/1174_2.png) [@Emma](https://openhealthhub.org/u/Emma)\ **Post date:** [20 May 2026 13:18 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/46 "2026-05-20T13:18:09Z")
Great work putting my cube in a visual - love it! ---
**Author:** ![Emma](https://openhealthhub.org/user_avatar/openhealthhub.org/emma/32/1174_2.png) [@Emma](https://openhealthhub.org/u/Emma)\ **Post date:** [20 May 2026 13:24 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/47 "2026-05-20T13:24:28Z")
Sorry I missed the last call. So will the teams link at the top now work every 2 weeks? I might not be able to get on the next call due to an important family birthday but will be there for the next ones. ---
**Author:** ![james.roberts](https://openhealthhub.org/user_avatar/openhealthhub.org/james.roberts/32/1166_2.png) [@james.roberts](https://openhealthhub.org/u/james.roberts)\ **Post date:** [23 May 2026 05:41 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/48 "2026-05-23T05:41:44Z")
Thanks all. Yes I will start a new thread if that’s ok so it keeps ideas together and avoids confusion. ---
**Author:** ![mayfield.g.kev](https://openhealthhub.org/user_avatar/openhealthhub.org/mayfield.g.kev/32/648_2.png) [@mayfield.g.kev](https://openhealthhub.org/u/mayfield.g.kev)\ **Post date:** [23 May 2026 06:15 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/49 "2026-05-23T06:15:55Z")
Thanks I wonder if we need to look at how we organise ourselves. Although we often start from the same place (patient pathway), we are likely to have diverged already. For example. - I am mostly focused on automating the patient pathway → I am **process/enterprise engineering** focused e.g. lab orders, data or document sharing, discharge reports, care coordination, etc. It is aligned to NICE, GIRFT, etc pathways. - Others will be clinical informatics focused. This tends to lead to **data engineering around EHR’s**. Processing engineering tends to treat data models from here as logical and implements them on the patient pathway often using different standards (e.g. define in openEHR/FHIR profiles and implement in HL7 v2, DICOM, FHIR, XDS, etc) - Others will be focused on applications on that pathway **application design** and **service design**. I"m not saying we should group this way, just we have different perspectives. We need to be conscious of people + process + technology ---
**Author:** ![james.roberts](https://openhealthhub.org/user_avatar/openhealthhub.org/james.roberts/32/1166_2.png) [@james.roberts](https://openhealthhub.org/u/james.roberts)\ **Post date:** [26 May 2026 18:37 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/50 "2026-05-26T18:37:19Z")
Thanks @mayfield.g.kev yes good points. I think the varied experiences and focuses is one of the benefits of building a community around this. Agree on deciding how best to organise and co-ordinate things - this would be useful to discuss alongside my previous thoughts on identifying a core philosophy/mission statement and values so everyone is on the same page. Very keen as well that there needs to be a focus on making action/progress - it can be very easy to talk about different issues and challenges. For this to work I think the real benefit might come by actually moving forwards and building. We might not get things right first time but if it creates interest and recognition of the value, the benefit of open source is people can tell you when something can be done better and suggest ways to do it! ---
**Author:** ![spdegabrielle](https://openhealthhub.org/user_avatar/openhealthhub.org/spdegabrielle/32/716_2.png) [@spdegabrielle](https://openhealthhub.org/u/spdegabrielle)\ **Post date:** [27 May 2026 15:33 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/51 "2026-05-27T15:33:11Z")
> [@Meet up: In house, open source tools for the NHS 28/05/26 - 18:30-19:30](https://openhealthhub.org/t/meet-up-in-house-open-source-tools-for-the-nhs-28-05-26-1830/2991/2): > > I would advise that breaking down the parts of an EHR into smaller components might be one way to gradually ‘eat the whole elephant’ of building an EHR. Is the SMART on FHIR a viable approach? I have to admit I’ve not seen it in practice, I don’t know the limitations, and I don’t know even if the standards are truly open/compatible with an open source effort? ---
**Author:** ![mayfield.g.kev](https://openhealthhub.org/user_avatar/openhealthhub.org/mayfield.g.kev/32/648_2.png) [@mayfield.g.kev](https://openhealthhub.org/u/mayfield.g.kev)\ **Post date:** [27 May 2026 17:14 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/52 "2026-05-27T17:14:35Z")
> [@spdegabrielle](#): > > Is the SMART on FHIR a viable approach? Only aware of EPIC and Cerner in the UK supporting this. In theory the NHS org I work for is capable of this, I just need to do the configuration … we haven’t got the ‘sexy’ genomic data in the data platform yet (not FDP, EPIC or Cerner!) ---
**Author:** ![spdegabrielle](https://openhealthhub.org/user_avatar/openhealthhub.org/spdegabrielle/32/716_2.png) [@spdegabrielle](https://openhealthhub.org/u/spdegabrielle)\ **Post date:** [27 May 2026 18:58 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/53 "2026-05-27T18:58:34Z")
It’s great to know it’s achievable for your trusts EHR. (I’m assuming they have a home grown or in-house/COTS hybrid EHR.) I was more thinking of SMART as a way for different teams to build the ‘whole elephant’ EHR - both front end components and backend _independently_ - though that seems like a certain amount of elephant is probably inevitable for the backend. ---
**Author:** ![riksmithies](https://openhealthhub.org/letter_avatar_proxy/v4/letter/r/e47c2d/32.png) [@riksmithies](https://openhealthhub.org/u/riksmithies)\ **Post date:** [27 May 2026 19:28 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/54 "2026-05-27T19:28:38Z")
SMART apps are intended as whole plug in applications. They could be a whole “screen” but may not have the granularity to be a UI component embedded in another UI. It also is not intended as a microservice architecture, though in theory it could communicate headlessly by reading and writing FHIR data. CDS Hooks is more like a microservice (a related FHIR based standard). ---
**Author:** ![mayfield.g.kev](https://openhealthhub.org/user_avatar/openhealthhub.org/mayfield.g.kev/32/648_2.png) [@mayfield.g.kev](https://openhealthhub.org/u/mayfield.g.kev)\ **Post date:** [28 May 2026 04:26 UTC](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944/55 "2026-05-28T04:26:22Z")
> [@spdegabrielle](#): > > It’s great to know it’s achievable for your trusts EHR. (I’m assuming they have a home grown or in-house/COTS hybrid EHR.) No, this is a quite different. We are a new NHS regional diagnostic organisation and we don’t have EHR (we have multiple LIMS). Our backend **database** system is a Data Platform, not an EHR. Our **API** to this data platform, is read only FHIR RESTful API (we also support write backs) Our method for **building applications** on top of this is SMART-on-FHIR and described here as ‘click through’ [https://www.england.nhs.uk/wp-content/uploads/2017/03/interoperabilty-handbk.pdf](https://www.england.nhs.uk/wp-content/uploads/2017/03/interoperabilty-handbk.pdf) It’s modular and layered with strong separation of concerns - I think what you are asking for? We are not the only organisation within the region with this architecture, many of the large NHS trusts (in our region) have or are capable of adopting a very similar API layer with SMART on FHIR (database/data layer is likely to be the EHR database) LInks to articles which describes genomic apps to use with our data platform (via SMART on FHR) are here: [SMART Cancer Navigator: A Framework for Implementing ASCO Workshop Recommendations to Enable Precision Cancer Medicine - PMC](https://pmc.ncbi.nlm.nih.gov/articles/PMC6141039/) [FHIR Genomics: enabling standardization for precision medicine use cases | npj Genomic Medicine](https://www.nature.com/articles/s41525-020-0115-6) NHS Trusts can use apps like this to access our data. [Previous page](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944.md?page=2)