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 Social Care Systems FHIR and Interoperability APIs - #5 by mayfield.g.kev
The underlying requirement + design I suspect is quite simple - if we keep standards and solutions to the minimum up front.
Emisweb has something like this called Family/Relationship links
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.
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.
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.
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 GitHub - cistec-com/openEHR2FHIRquestionnaire: This script converts an openEHR web template (JSON) to one or more FHIR Questionnaire resources (JSON). You can generate multiple language variants, in case the respective translation is included in the web template. The FHIR version can be selected (currently supports R4 and R5). · GitHub
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 EU Health Data API - European Interoperability Specifications for Digital Solutions in Healthcare
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.
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
Would be great to get a rough idea of numbers so if you are able to click that you’re attending 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. 
James
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…)
Also in case not everyone has seen this:
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…
Ignore me, the link is Join conversation
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.
sct tools for SNOMED GitHub - pacharanero/sct: SNOMED-CT tooling, brought into the 21stC. RF2 → NDJSON → SQLite | Vector | .arrow, | .parquet | .md | refsets | .codelist | MCP · GitHub
Digital Growth Charts GitHub - rcpch/digital-growth-charts-server: RCPCH's open source Digital Growth Chart API · GitHub
There are others on my GitHub 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.
The 50 key rules from the NHS CUI is here
@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.
I’ve put a list of open source + standards I’m aware on here Open health sources
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. The WHO SMART Guidelines are a good example of this.
For example: WHO Immunisations provides background for IHE PCC Vol 1 - Chapter 6 Immunization Content Module. 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!
For me these stories are exactly why coding, especially in public sectors, needs to be open source.
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:
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.
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
Optimising, building and championing some pre-existing concepts and frameworks such as the NHS CUI adds value and brings focus to this field
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
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.
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 (1.5 MB)
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.
Meeting link 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
