# A team to develop, in house, open-source tools for the NHS **Category:** [open forum](https://openhealthhub.org/c/open-forum/9) **Created:** 2026-03-19 09:30 UTC **Views:** 940 **Replies:** 54 **URL:** https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944 --- ## Post #1 by @james.roberts Hi everyone, I'm James, a GP in South Devon, current Deputy Chair of the RCGP Health Informatics Group and Secretary of the BCS Primary Healthcare Specialist Group. I know this conversation comes up regularly. I have considered it for a while and was inspired further by discussions with Marcus and on this forum. I think now is the time to act. **We need a team to develop, in house, open-source tools for the NHS.** We need to bring together a group of highly motivated individuals who can bridge the gap between clinical experience and software development. The aim would be to start building a catalogue of production-grade tools available for deployment across the NHS. The benefits of this approach are significant: * Aligns well with the quintuple aims of improving healthcare systems: improved patient experience, better health outcomes, reduced costs, improved clinician wellbeing, and greater health equity * Development is clinician-led, meaning we identify the actual problems we face and how best to solve them. Finding and building ‘**solutions for problems**’ not trying to find ‘**problems for solutions**’. * We can be agile, move quickly and take advantage of new developments as they emerge * We can help reduce/avoid some of the potential negative aspects that can occur with commercial tech such as - the need to improve profitability, ‘stickiness’/vendor lock in, restrictive contracts, investor pressures, questions around how data is used. I recognise that open source doesn't mean free/zero cost. There will be hosting, maintenance, and other costs such as AI inference if used in tools. There is also the factor of the cost of our time in contributing to any projects. But I think there are some realistic routes to sustainability: * Possibility of commissioned projects and funding * Clinical safety and implementation work * User training * Hosting * Offering services to international providers if this can be established as a reputable and reliable source of healthcare tooling If we need a ‘vehicle’ or brand, I have CliniPrompt we can use, though I'm not fixed on this and open to alternatives or joining forces with existing groups. **Interested in peoples thoughts on this. I thought I’d set up an introductory call in the next couple of weeks. If you want to be part of this, let me know and I'll send you the details. It will be important to have both clinical and more technical focused people involved.** **James** ## Meeting [event start="2026-04-28 18:30" status="public" name="NHS In-House Open-Source Dev Team Initial Meeting" location="https://teams.microsoft.com/meet/337140683654022?p=qdLGD8Ihw3IEg9T6rp" timezone="Europe/London" end="2026-04-28 19:30"] [/event] > EDIT: @pacharanero added an Event to this post --- ## Post #2 by @mayfield.g.kev Happy to attend an online event. My view is also ‘**solutions for problems**’ but probably not a solution. Defining problem + user/pathway requirement well enough to get a good solution is a known issue. For example in NHS England - a clinical problem is turned into a solution before it hits developers, this eventually leads to ‘**problems for solutions**’ --- ## Post #3 by @Cotswoldsmaker I would love to be part of this. Open source all the way baby. Let me know where to sign up! Mark --- ## Post #4 by @paul.richardson Count me in too. We are doing pretty much what you’ve described, but just in relation to Open Integration Engine, the rescue fork of Mirth Connect. We have put it through DCB0129, have our DSPT, ISO27001 etc and have had our first couple of successes in persuading NHS Trusts and system vendors to migrate to OIE and avoid license costs from NextGen. We’re on the cusp of making self-provisioned OIE instances available for non-production purposes. Let me know if any of you are interested in kicking the tyres. --- ## Post #5 by @pacharanero I'm in. Great to see there is appetite for doing this stuff. My thoughts below: ### Agentic coding Some of the work that used to take many months in the past is now much faster since the advent of LLM-assisted coding - but it does still need some technique to make it work! And of course all the clinical safety, MedDev, and data standards that were always required are still required, so although the bottleneck has moved, there is still challenge. As clinicians and health IT experts we are advantaged now because we have domain specific knowledge. ### Existing projects I would strongly recommend that we don't start loads of new projects if we can find existing projects to contribute to. One of the side-effects of agentic coding is that it's going to result in a GitHub-pocalypse global proliferation of low-value open source personal side-projects, when that effort would be better spent in collaborating on a smaller number of high-quality projects. ### Organisations Having seen many organisations rise and fall in a decade and a half of health tech - I would advise against hitching this wagon to any orgs that we don't control - ie NHSE/D, DHSC etc. James' suggestion of CliniPrompt would be fine. I also own the https://github.com/orgs/openhealthhub-org/repositories which I know @mayfield.g.kev has already made use of. --- ## Post #6 by @mike.bainbridge Excellent idea - Keep in mind thst there are useful resources all over the place. This might be handy for example- Smart forms using FHIR and SNOMED - admittedly from the other side of the world but maybe worth a look and a fork ! https://github.com/aehrc/smart-forms https://smartforms.csiro.au/dashboard/questionnaires The clinical content is also worth thinking about early - I know Marcus has many scars on this one.. --- ## Post #7 by @Emma Count me in. All for the NHS taking control of its own technology and getting standards aligned across the country. --- ## Post #8 by @robdykedotcom On a related note, it’s been 14 years since the first [NHShackday](https://nhshackday.com/) and this weekend (21/22 March) the 30th event is being held in Cardiff. Open source is EVERYWHERE in the public sector. Here’s a [detailed deepdive into the 24,000 repositories across 186 UK Govt organisations](https://www.uk-x-gov-software-community.org.uk/xgov-opensource-repo-scraper/) - lots of NHS projects to be found. --- ## Post #9 by @mayfield.g.kev [quote="mike.bainbridge, post:6, topic:2944"] This might be handy for example- Smart forms using FHIR and SNOMED - admittedly from the other side of the world but maybe worth a look and a fork ! [/quote] I suspect we would need to split into teams. From my own experience the NHS does a poor job around forms - I was at a Leeds open source event where this popped up, yet again for referrals. Technically this has well known patterns: - complete a form and click submit - in secondary care this is often transformed into HL7 for transmission - however more likely, it’s turned into PDF and emailed. - complete a form and decompose into resources for reuse (← This is Structured Data Capture and allows for existing data to be used to pre-populate questions) - clinical informatician will often say the answer is openEHR (this actually can work with Structured Data Capture, and the above but saying so may get you black balled) I think putting this altogether would save the NHS millions of hours (as long as we accept all these patterns are correct, and don’t go down “One Ring to Rule” them all route). --- ## Post #10 by @mayfield.g.kev p.s. In my day job I’m working on this problem This (potentially opensource) app renders our Genomic Order form https://project-wildfyre.github.io/domain-archetype/?q=https:%2F%2Fnw-gmsa.github.io%2FQuestionnaire-GenomicTestOrder.json description of the form is here which is SDC ready is here https://nw-gmsa.github.io/Questionnaire-GenomicTestOrder.html The rest of the spec https://nw-gmsa.github.io/LTW.html covers how it sent to a LIMS and how the LIMS shares it - I don’t directly cover Structured Data Capture but the pattern is present (in NHS Trusts, they implement a version of this form and it’s gets turned into HL7 v2 for the electronic order). This is also roughly how clinical referrals (and pathology and imaging orders) work. --- ## Post #11 by @jonnyry Hello, I'm interested in joining the call. Thanks --- ## Post #12 by @james.roberts Thank you everyone! Great to see such positive responses and enthusiasm. To me it makes sense that if we can organise a structured and co-ordinated approach to this as well as shining a light on the outputs and potential, it would be a good direction. At present, I imagine there are many clinicians and teams with ideas, working in isolation. A lot of these projects with potential might get stuck at early stages for some of the reasons @pacharanero mentions or their outputs do not reach others that may benefit. Agree about the bottlenecks shifting with the barriers to writing code and the requirements for large development teams reducing. Will need to stay clear of the idea of ‘vibecoding’. I see it as having a system where not a single line of code gets written until a plan and specification for each aspect of a tool is considered and agreed. The new bottlenecks mentioned - device regulation, data standards etc are aspects that I think members of this community and frontline clinicians may be some of the best placed to address. Looking at calendar and upcoming Easter holidays, can I suggest **Tuesday 28th April 18:30-19:30** as a time for anyone interested in being involved to meet? Do not worry if you are unable to make this time. I’m happy to talk separately. This should give me some headspace to put some thoughts and plans together. In the spirit of open source I will share the document when available and encourage any suggestions. :grinning_face_with_smiling_eyes: Please also keep the ideas and discussions coming as there has already been some interesting discussion on this thread. Thanks again all, James --- ## Post #13 by @pacharanero [quote="james.roberts, post:12, topic:2944"] can I suggest **Tuesday 28th April 18:30-19:30** as a time for anyone interested in being involved to meet? [/quote] I can make this. --- ## Post #14 by @robdykedotcom I can make this --- ## Post #15 by @mayfield.g.kev Ditto, can make it --- ## Post #16 by @pacharanero Irritatingly, despite it being 2026 and all, Discourse still doesn't really have a great way to send out a Calendar invite which will be notified out by email and contains the right mimetype `text/calendar` that you can all get it auto-added to Calendar. What it does have is the [ability to add an Event to the first post in a Topic](https://meta.discourse.org/t/creating-and-managing-calendars/283773), so I will take the liberty of doing this for @james.roberts right now. Once I've done that you can click on the … button in the top right of the Event and there is an Add to Calendar option. I am so annoyed at this lack of a basic feature in Discourse I've [raised a feature request](https://meta.discourse.org/t/add-to-calendar-ics-ical-attachments-for-events-in-discourse-notification-emails/399329). --- ## Post #17 by @pacharanero OK done [![image|690x343](upload://c5c8ozfOolILWX9hROsO9MBpzQ2.png)](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944#meeting) Go to top post https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944#meetingto see and use the Event. --- ## Post #18 by @mayfield.g.kev On ideas. I think health is too focused on recording data and is biased to data doctors want. This means workflow or patient care coordination is not as good as it could be - this is often not supported by primary, social care, social prescribing or community systems (nobody wants to pay for it?) For example around my dads care, all the social workers and nurses had minimal support from tech (other than texts, emails, etc). They were all trying to work out who should do what, when and what for. Most had no access to my dads basic record - some levels of interop between suppliers were embarrassing (EOLC/ReSPECT form arrived 2 days after it was needed, we had an information governance discussion to get it to his house) Within this area is a large number of forms (@mike.bainbridge point) which includes a lot of transcribing from existing data sources. Also in this area is physical activity and virtual wards (both are patient monitoring probably using smart devices). --- ## Post #19 by @Emma Agreed, whilst clinical data is important the social daily workflows are just not there. With my mothers care, I recognise the staff change overs and varying medical inputs it’s so hard to keep a track on simple basic care needs. --- ## Post #20 by @Emma On another idea- I once heard of a record system that connect family records together. I think this could be really inspiring. Not necessarily seeing those other records but understanding the core fundamental aspects of stresses and support networks could be really interesting as a concept. Families, student homes, community housing make such a difference to wellbeing. --- ## Post #21 by @mayfield.g.kev Might be an idea to get these noted down and then we can talk about solutions? Slightly engineering the solution here, as I can see some of what is discussed above is directly related to this post https://openhealthhub.org/t/social-care-systems-fhir-and-interoperability-apis/2951/5 The underlying requirement + design I suspect is quite simple - if we keep standards and solutions to the minimum up front. --- ## Post #22 by @jonnyry Emisweb has something like this called Family/Relationship links https://www.herohealthsoftware.net/primary-care/emis-support/article/how-do-family-relationship-icons-function-in-emis-web-and-what-do-they-represent --- ## Post #23 by @mayfield.g.kev I’m a little biased on this idea due to a recent family episode I was thinking of apps to help a family + patient through a cancer diagnosis (possibly aligned to macmillan - which I found to be very good) It doesn’t have to be much to begin with. As a family we started using **goggle drive** to store NHS documents, and we would show these to NHS or social care staff when they didn’t have access to them. Communication was via **WhatsApp**. What would have been good was access to both GP and Secondary Care systems, adding EPIC/Meditech/Oracle-Cerner records to an app should be easy and then at a later stage add GP record (IM1 Patient Facing Sercices - PFS). These could be combined so that family/patients could use these to show other NHS / health / Social care staff the patients records. Longer term this view, can be exported in IPS format which probably would all non UK staff to view patients records (for example when the person is on a pilgrimage or on holiday). Is also something called a Cancer Survivor Passport which could also be generated from above. --- ## Post #24 by @stephen There is of course the NHS app, but it is seems limited to what integrations your GP and hospitals have enabled. An app for the patient and family is a brilliant idea. --- ## Post #25 by @ian I support this Kevin (having been in similar circumstances). The goal of the London Universal Care plan was to try to take some of this burden (on both staff and patients/carers) About Me, personal care networks, LPA, communication needs, functional needs, assistive equipment needs, carer contingency, etc, etc All of this is ‘soft stuff’ but hugely valuable, and takes a lot of frustrating time and effort to keep re-communicating every time the person hits another service or pathway. Almost none of it is specific to any condition or pathway. Plus this is a ‘primary record’ and source of truth for this kind of ‘information for life’ It is all directly visible/ shareable via the NHS app (with limited patient writeback being rolled out) and structured via openEHR/FHIR API’s should third-party apps want to consume it. Although I think we are probably a bit ahead in London, other Shared Care Records are starting to develop similar capacity, so this is a bout the concept not any particular product or tech approach. Next phase is adding condition-specific escalation plans - e.g. sickle Cell, epilepsy, asthma. We are also involved in a bid for EU-Horizon funding to replicate the approach across several European countries, and hopefully extending the IPS content to be more supportive of this kind of info. --- ## Post #26 by @ian ![image|500x500](upload://aGKIcCwzv4cigZBtGJSzn9dFGiZ.jpeg) https://gps.northcentrallondon.icb.nhs.uk/digital-tools-in-practice/better-universal-care-plan-online-access If there was interest, I could setup an end point that would mimic the UCP content using open-source components. The native API is openEHR but we can build FHIR adapters via tools like https://github.com/cistec-com/openEHR2FHIRquestionnaire?tab=readme-ov-file --- ## Post #27 by @mayfield.g.kev I wonder if you could start with something like this, combining two LHCRE projects. Obviously doesn’t work country wide but it’s a start (some other regions may have a HIE like Yorkshire, not sure of capabilities of Cerner HIE) Roughly the API presented to the App follows this API from IHE/HL7 EU https://euridice.org/eu-health-data-api/ This API doesn’t have a simple hook for openEHR (could convert to a PDF though and also return a openEHR converted to FHIR QuestionnaireResponse ← just keep it simple?). YHCR is roughly compliant (wrong FHIR version) with HL7 IPA Linking to EU might also be a way to get funding. ![Screenshot 2026-04-01 at 16.55.14|690x230](upload://fwPlJQt7x9OlxYajE16cy845pCo.png) --- ## Post #28 by @james.roberts Looking forward to seeing those that can make it next week! I have set up a link for the meeting [NHS In-House Open-Source Dev Team Initial Meeting | Meeting-Join | Microsoft Teams](https://teams.microsoft.com/meet/337140683654022?p=qdLGD8Ihw3IEg9T6rp) Would be great to get a rough idea of numbers so if you are able to [click that you're attending](https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944#p-6220-meeting-1) or send me a message I'd appreciate it. Love the comments and ideas so far. Improving continuity and ensuring that the correct data is made available and interpretable to healthcare staff and patients is essential. The healthcare system is becoming increasingly complex and so finding ways to standardise data and ensure interoperability are needed. Keep the ideas coming. Would welcome any questions for discussion and also thoughts on what it would be good to pin down on this initial meeting. I will aim to put together a brief/plan later this week. :slightly_smiling_face: James --- ## Post #29 by @pacharanero If we haven't decided yet on the video meeting link, may I suggest https://meet.jit.si/ as an option - it's free and open source and you can reuse the same link. For example all our meetings from the RCPCH Incubator happen in `https://meet.jit.si/rcpch-incubator`. (when you realise how much time is wasted globally, making new unique links for recurring, regular meetings of the same people, you do start to wonder how Teams is so popular...) --- ## Post #30 by @pacharanero Also in case not everyone has seen this: https://openhealthhub.org/t/clinicians-who-code-un-conference-june-20th-21st-2026-patch-york/2970 Quite a lot of the same people for this call would possibly want to come to a CwC conference. Non-clinicians would be welcome, especially if you want to present something... --- ## Post #31 by @pacharanero [quote="pacharanero, post:29, topic:2944"] If we haven’t decided yet on the video meeting link, may I suggest https://meet.jit.si/ as an option - it’s free and open source and you can reuse the same link. [/quote] Ignore me, the link is https://teams.microsoft.com/meet/337140683654022?p=qdLGD8Ihw3IEg9T6rp --- ## Post #32 by @pacharanero Great to have an initial conversation this evening. I dropped into the chat some of the stuff I've been working on, and I think that initially working on small components that may one day add up to a more complete whole. To this end I'm picking off small bits, but I do have some more ambitious ideas in the pipeline. --- NHS CUI https://github.com/pacharanero/nhs-cui `sct` tools for SNOMED https://github.com/pacharanero/sct Digital Growth Charts https://github.com/rcpch/digital-growth-charts-server Medical Markdown https://github.com/pacharanero/medical-markdown NHS Number https://github.com/uk-fci/nhs-number --- There are others on my [GitHub](https://github.com/pacharanero) but that should give you an idea. I am trying to make each piece easier to use, lower the bar for participation, reduce complexity, and standardise. Too much of health tech is highly bespoke and this bespoke-ness is one reason everything is clunky yet *incredibly* expensive. It would be good to have some regular meetups and share ideas and knowledge. If anyone wants to help with any of the work I'm doing, there's no need to be technical, a great deal can be added simply by reading and sense-checking some of the documentation and specifications and feeding back. --- ## Post #33 by @pacharanero The 50 key rules from the NHS CUI is here https://github.com/pacharanero/nhs-cui/blob/main/50-key-cui-rules.md --- ## Post #34 by @jonnyry @pacharanero pleased you’re resurrecting and modernising the NHS CUI, there were lots of useful things in there, like common date formatting, NHS number formatting, patient banners etc. It was a shame when NHSD/E/X decided it was no longer needed, in favour of their design system - which arguably serves a different purpose. --- ## Post #35 by @mayfield.g.kev I've put a list of open source + standards I'm aware on here https://openhealthhub.org/t/open-health-sources/2980 I've been a bit liberal on what I view as "open", might need to narrow that down. As a developer I tend to favour focusing on the clinical side first, it tends to be the weakest part of software development (analysis and design) and explained poorly in the NHS. Ideally this documentation is expansion of clinical pathways from NICE and [GIRFT](https://gettingitrightfirsttime.co.uk/). The WHO SMART Guidelines are a good example of this. For example: [WHO Immunisations](https://www.who.int/publications/i/item/9789240099456) provides background for [IHE PCC Vol 1 - Chapter 6 Immunization Content Module](https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol1.pdf). This would have been really useful for me as a developer working on Imms over the years - rather than fast ball during COVID when the clinical pathway description finally got to developers! --- ## Post #36 by @Emma https://www.theguardian.com/commentisfree/2026/apr/30/i-took-an-algorithm-to-court-in-sweden-the-algorithm-won?CMP=Share_iOSApp_Other For me these stories are exactly why coding, especially in public sectors, needs to be open source. --- ## Post #37 by @mayfield.g.kev Do we need open collaboration also? The article reminded me of **Transfer of Care Initiative** between secondary and primary care. NHS England said it should be this https://digital.nhs.uk/services/transfer-of-care-initiative which contained a text book clinical informatics **Composition** answer. However for most NHS Trusts this was a really difficult ask, many secondary care trusts were moving these discharge reports from paper to PDF and this forum had many questions (from developers) on the alternatives (search for Kettering XML and you can find the questions). Tech has moved on now and large NHS Trusts (with advanced EPR), might be able to support **Composition** but the practical answer is still limited to: - Share Documents (including Composition) via something like NHS Englands NRL. - Send Documents either using HL7 v2 ORU_R01 or MDM_T02 - Share Data via an API (limited to NHS Trusts with US EPR) A side issue is NHS Trust tech is designed for wider workflows and user needs, not single workflows/data exchanges like NHS England. Fingers crossed - NHS England will go for the NRL answer above for **Single Patient Record**, at a stretch the Data API also. These should establish a useful baseline to improve data quality. --- ## Post #38 by @james.roberts Thank you everyone that attended. It was great to meet you all and hear the shared enthusiasm! Some of my key takeaways from the initial meeting are: 3 strands emerged for me 1. Optimising, building and championing some pre-existing concepts and frameworks such as the NHS CUI adds value and brings focus to this field 2. Creation is just one part - delivery is likely the bigger challenge. We could build the best tools but if no-one is able to deploy them they will sit unused. Looking at frameworks to aid with deployment, security, clinical safety is an area we are going to explore 3. It keeps coming back to the EPR. A truly patient centred EPR designed from the ground up to work with open standards and easily integrate with other tools seems to be a core need. The alternative approach of designing lots of patches and tools to work with current systems seems like the wrong approach Some other points I really liked from the meeting were the discussion of how, when designing an EPR we have the exciting possibilities of viewing it from different perspective. The analogy of a 3d cube with the EPR held inside. You can build in to the design the idea of how it will be viewed from the different perspectives of a clinician, a patient, an organisation - each of whom have different requirements in the information that needs to be surfaced and presented. ![cube|505x500](upload://gSaaSM8xGiZ6esFBc0EVpeqQBIh.gif) We talked about needing a set of shared principles and I think this as well as a mission statement would be important. I have added my brief slides below. One aspect of this that I felt was important. This should not be seen or labelled as a budget/cost-saving option. The true benefit (and focus) should be on the opportunity to have tools that are truly designed to be interoperable and built from the ground up to meet the needs of our patients, clinicians and the service. By doing it in this way it can encourage true open collaboration between teams from across the country where solutions to problems can be more easily shared and implemented elsewhere. We were keen to keep the momentum going so plan to meet again on Thursday 14th May 18:30-19:30. Please join if you were not able to make it to our first meeting or reach out/post here if you have ideas you would like to discuss. James [NHS In-House Open-Source Dev Team, Initial Meeting.pdf|attachment](upload://pF6jE2tJXtT1xSzHxqOIKwhstSa.pdf) (1.5 MB) --- ## Post #39 by @mayfield.g.kev [quote="james.roberts, post:38, topic:2944"] It keeps coming back to the EPR. A truly patient centred EPR designed from the ground up to work with open standards and easily integrate with other tools seems to be a core need. The alternative approach of designing lots of patches and tools to work with current systems seems like the wrong approach [/quote] It's a lot easier to make existing EPR's appear to be the same in APIs and Events layers. Focusing on the database is a lot harder - you have too many people, organisations and care settings to agree. This is how central NHS approaches data (and interoperability) standards - we don't have that many API and Event standards. Central NHS may alter it's approach from GP to Patient but it will be mostly the same design. The former style is quite widespread in secondary care and working quite well. It is strongly focused around the patient pathway instead of EHR databases. --- ## Post #40 by @james.roberts [Meeting link](https://meet.jit.si/NHSInHouseOpenSourceTeamMeeting) for tonight 18:30-19:30 for those that are keen to join - we are using @pacharanero suggestion for the video call, looks good! Have a great day, James --- ## Post #41 by @pacharanero 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. --- ## Post #42 by @olizilla 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 * 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 * 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! --- ## Post #43 by @pacharanero 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). --- ## Post #44 by @olizilla 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. --- ## Post #45 by @james.roberts 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 --- ## Post #46 by @Emma Great work putting my cube in a visual - love it! --- ## Post #47 by @Emma 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. --- ## Post #48 by @james.roberts Thanks all. Yes I will start a new thread if that's ok so it keeps ideas together and avoids confusion. --- ## Post #49 by @mayfield.g.kev 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 --- ## Post #50 by @james.roberts 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! --- ## Post #51 by @spdegabrielle [quote="pacharanero, post:2, topic:2991"] 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. [/quote] 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? --- ## Post #52 by @mayfield.g.kev [quote="spdegabrielle, post:51, topic:2944"] Is the SMART on FHIR a viable approach? [/quote] 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!) --- ## Post #53 by @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.) 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. --- ## Post #54 by @riksmithies 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). --- ## Post #55 by @mayfield.g.kev [quote="spdegabrielle, post:53, topic:2944"] 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.) [/quote] 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 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: https://pmc.ncbi.nlm.nih.gov/articles/PMC6141039/ https://www.nature.com/articles/s41525-020-0115-6 NHS Trusts can use apps like this to access our data. --- **Canonical:** https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944 **Original content:** https://openhealthhub.org/t/a-team-to-develop-in-house-open-source-tools-for-the-nhs/2944