Ideally this works with the FHIR RESTful API meditech, yorkshire + humberside, oracle and EPIC support (and AWS Healthlake).
I’m after a simple open source clinical portal which would:
a. Allow a user to find a patient
b. Display medical record including: Observations, Condition, Procedures and Documents.
It may allow customisation - e.g. for Observations, I have Genomic Variant and Diagnostic Implication.
I’m not aware of any open source clinical portals, but there are clinical portals in use in the NHS which ‘could be open sourced’.
As part of work with RCPCH delivering Digital Growth Charts we’ve worked with a number of NHS Trusts who have developed their own in-house clinical portals, but they haven’t open sourced them for a few common reasons:
(Mainly) Insufficient internal developer resource to manage the initial open sourcing work
Lack of an organisational incentive to open source the portal
Fear of liability, costs, or additional work resulting from open sourcing
A (probably reasonable) low expectation of demand from other Trusts to adopt another Trust’s open source portal
(Frankly hilarious) Trust Finance Director fantasies around the vast sums of money the Trust could make from commercialising its homebrew portal, meaning that any talk of open sourcing is idiotically equated with “we’d be giving away ££££millions in IP”
An inadequate understanding of the potential of the NHS to save a lot of money by coordinating and collaborating on a few simple OSS projects like this
An almost criminal willingness to waste NHS (taxpayer’s) money on building the same thing again and again, in secret, badly, across dozens of trusts
(non-exhaustive list)
It might be possible to make friends with a trust which has a homebrew clinical portal that they might let you open source on their behalf? I could put you in touch with some of the devs behind the scenes @mayfield.g.kev (for the 3-4 I’m aware of). And a wider appeal on NHS Developer forum might come up with more trusts?
I might have something to at least demonstrate the idea (it’s not pretty, I’m not a front end developer).
I wrote it for NHS England but at the time it was reliant on a standard API which wasn’t around then but since then we’ve got several trusts with EHRs and regional HIE’s with this API.
Amusingly (or not), none are explaining how they work and why it is easy for Oracle/Cerner, EPIC and Meditech (and my project) plug into them without major development work.
It’s a like it’s an in plain sight secret.
I’ll ask on Digital Health Networks for you, but I’d be surprised if any have. What a fucking shitshow. ALL THAT MONEY and still the NHS doesn’t own the fucking IP.
@pacharanero I tend to see an app and backend API as two separate things.
In the US, the government told EHR suppliers to provide same API and they called that US Core API ← backend
When they did that, application (frontend) providers started building app which would work with several EHR’s with minimal change → this is a catalogue of some Featured Apps
I’m aware this basic API idea has been confused in the UK (which is why I’ve tried to leave FHIR out of the conversation, as that tends to spiral into health informatics data modelling conversations)
So if I want to know a patients weight in EPIC/Meditech/Cerner/YHCR the query is something like
GET /Observation?patient=ABC&code=29463-7
For YHCR (and Somerset) this might be GET /Observation?patient=ABC&code=27113001
Diagrams is wrong way round for us….. The laboratory will have a genomic CDR (is a FHIR Server) and I’m after an app to view it (for a hospital, GP, etc)
I think the LHCREs are more about connecting the EHRs rather than being an EHR. For the connection part, the source for the YHCR is indeed open source:
NHSE does indeed have consistent patterns. Remember in 2015-2017 when NHSE went ‘peak open source’? ABSOLUTELY NOTHING from that era was actually meaningfully open sourced. Nothing remains of that fervour. No projects achieved escape velocity.
Many LHCRE did the same but these mostly became commercial (some pre built US products where clinical portal is often called Health Information Exchange). ← Most practitioners will focus on the application names such as CernerHIE.
Hidden behind these applications was a lot of API standardisation, in US this was around FHIR + RESTful APIs, somehow in the UK we made FHIR all about data standards (actually this is FHIR profiles and so has overlap with openEHR). The former doesn’t have overlap with openEHR and it is the area most developers will touch FHIR via an API, not profiles.