A team to develop, in house, open-source tools for the NHS

open forum
41

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.

42

How doo! @james.roberts and I had a good call. I’m on board too!

We talked about

…and keeping this regular to get some momentum! See you in 2 weeks for the next one!

43

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.

44

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.

45

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

46

Great work putting my cube in a visual - love it!

47

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.

48

Thanks all. Yes I will start a new thread if that’s ok so it keeps ideas together and avoids confusion.

49

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

50

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!

51

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?

52

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!)

53

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.

54

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).

55

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: SMART Cancer Navigator: A Framework for Implementing ASCO Workshop Recommendations to Enable Precision Cancer Medicine - PMC
FHIR Genomics: enabling standardization for precision medicine use cases | npj Genomic Medicine
NHS Trusts can use apps like this to access our data.