Our strategy at Interneuron is a platform+apps approach so the platform is fundamental to our success with almost half of our engineering team focusing on it at any one time. In fact, one of our core engineering principles is ‘Platform-first’ – if something can be centralised, shared and re-used then it should be a service or function of the platform rather than the client.

We are proud of the architecture we’ve designed and implemented so far, but we still have a long way to go. We 

 and with several NHS deployments under our belt, we want to take a moment to share some of the thought process that has gone into designing our flagship product – Interneuron Synapse.There are three aspects of Synapse that set it apart:

One of the biggest benefits of a platform+apps approach is the ability to re-use data across applications – but without a structured, human readable and extensible data model its just not possible. Whilst there are some attempts to standardise Health+Care data models, we didn’t feel any of these were mature or extensible enough for our customers. Interneuron Synapse includes our Studio tool for managing, extending and building your own data models.

We want it to be as easy to get data out of the platform as it is to get data into it, but we also do not want to constrain how the data is accessed. We have therefore implemented:-

Dynamic object-based APIs – These APIs allow the persistence, update and logical deleting of any object within the platform

List and Base View APIs – These APIs allow you to create your own views of the data through the creation of SQL views which are then exposed, through our security model as APIs.

Data Export Services – We know that sometimes you need to extract large amounts of data – for use-cases such as Business Continuity, so we enable the generation of extracts based on any List or Base View.

Anonymisation and Pseudo-Anonymisation APIs – For research and other use-cases where identifiable datasets are not permitted.

We believe it’s important to be able to go back to any record at any point in time and be able to see exactly what was available at that point – therefore, we made the decision that our platform would be insert-only. The platform automatically versions, collapses and archives your data so you don’t need to worry about it. A full audit trail is available through our Open APIs too!

These are just some of design decisions we have made to date and we invite you to view our source code on 

 – all feedback is welcomed. In a future blog post, we will take you through our microservice architecture pattern for Interneuron Synapse.

There are many Health+Care specific platforms now widely available and in use throughout the NHS. However, not all platforms are equal.

Not all platforms are equal

The Health+Care IT industry has a history of software suppliers holding their customers to ransom. Whether that’s through controlling (read: limiting!) access to their data, charging extortionate amounts for integrations or shelving entire products and forcing customers to “migrate” to new and more expensive solutions!

At Interneuron, we do things differently. Our software is open source, we are a not for profit Community Interest Company and we ensure our software is “open-by-design” through our Open APIs.

Our open Modular Care Record has been designed to keep things simple for our customers and users. The core platform (Synapse) handles data integrations, terminologies, calculations, configurations and all commonly used application services, so this need only be done once. The responsive web client user interface framework (Terminus) is reused across all our modules and is designed to make it easy to search and filter groups of patients, based on location, specialty, team or any other criteria that is available. With the fundamentals taken care of we have been able to focus on the details of each module (e.g Observations, Fluid Balance, Assessments and Electronic Prescribing among others) to ensure they are fit for purpose and easy to use.

Our modular approach means that you are able to implement only the modules you need, and our integration technology allows us to integrate with your existing systems as you require.

We want our customers to be able to ‘Keep their options Open’.

To that end, we are also pleased to announce an industry first – we’ve deployed our solutions on a publicly available playground for anyone to see what our software is capable of:

Lastly, we want to improve transparency on our open source releases. In the past we’ve been slow to publish all of our developments to the public repositories on GitHub. Today, that changes – we are proud to announce our automated pipelines for publishing to GitHub: 

The Health+Care IT industry has a history of software suppliers holding their customers to ransom. W hether that’s through controlling...

Keep your options Open

Introducing Interneuron's Modular Care Record:

https://interneuron.org/wp-content/uploads/2022/01/The-Modular-Care-Record-final.pdf

Introducing Interneuron's Modular Care Record: https://interneuron.org/wp-content/uploads/2022/01/The-Modular-Care-Record-final.pdf...

Interneuron Modular Care Record

The challenge for medicines interoperability

For medicines interoperability to work across our healthcare system, standards are essential. But complying with these standards can often be harder than it seems. The PRSB information standards have the potential to make medicines data truly interoperable – but interoperability will also require a change in the way we prescribe medicines in secondary care. Molecule based prescribing (prescribing just the name of the active ingredient) is helpful in many ways – but for interoperability to work, we need to document the actual medicinal products a patient leaves hospital with, or there will always be a need for humans to clear up the ambiguity.

There are two ways of thinking about a therapeutic medicine – and while both are valid, they are at times, unhelpfully incompatible – or should I say un-interoperable.

A pharmaceutical organisation develops, tests and trials a medicinal product. The product is a ‘preparation’ of (one or more) active ingredients and if present, 

 has a form, a weight a manufacturer and a price. The product is ‘licenced for use’ in certain situations for specific clinical indications. It is sold to healthcare organisations who may use it for a licenced indication or (at their own risk) for an unlicenced indication.

 that the pharmaceutical organisation has tested, the 

 that has undergone a clinical trial, the 

 that has the clinical indication for use.

The molecule is the active ingredient. It is the actor within a biological process; the subject of academic research. Supporting evidence for the molecule is generalised from the clinical trials of actual medicinal products. The molecule is considered in the abstract. It is independent of any product. It does not have a form, a weight a manufacturer or a price.

In secondary care, the prescribing preference has been to use molecule-based prescribing. To use the correct jargon, hospital prescribers tend to prescribe Virtual Therapeutic Moieties (VTMs). The VTM is just the name of the active ingredient and a VTM prescription includes the dose and posology – for example: ‘Paracetamol – 500mg – 4 times a day until stopped’.

The VTM prescription provides several advantages:

A single VTM prescription can cover multiple different medicinal products and formulations so the prescriber can leave, to their pharmacy and nursing colleagues, more options as to what to actually give the patient:

Options related to which brand is the most cost effective

Options related to the specific form/formulation

Options related to the route of administration (prescribing for multiple routes: Oral, Intravenous etc)

The prescriber only needs to remember the dose of the active ingredient and the posology

Your prescription must be reviewed by pharmacy/nursing staff – who may correct prescribing errors

The options leave open significant ambiguity:

Ambiguity between different potential preparations

e.g. Lithium is available as two salts, lithium carbonate and lithium citrate, which are not dose equivalent.

Did the prescriber want the patient to have a liquid, a tablet or a capsule?

Did the prescriber want the patient to have a gastro-resistant or modified release formulation?

Unintended over/under dose when multiple routes are prescribed

Some medicines are far more potent when given intravenously than orally

VTM prescribing for multi-ingredient drugs

e.g. Prescribing 500 mg of Co-codamol is not a valid prescription. Co-codamol consists of two active ingredients with different doses e.g. 15 mg of Codeine phosphate and 500mg paracetamol. Prescribing 500mg of ‘Co-codamol’ is not a valid prescription.

Error correction by pharmacy not feeding back to prescribers

Where prescribers rely on pharmacy to correct errors and do not get adequate feedback – prescribing errors will continue.

Pharmacy dispensing cannot be automated as there are too many potential products that could match a VTM prescription.

Primary care providers, who sometimes have their own on-site pharmacy, have long understood the practical and financial benefits of prescribing products in primary care. The vast majority of primary care prescription are simple formulations (tablets, inhalers, creams) and their product based prescriptions do not require further interpretation before dispensing.

Our problem occurs when medicines data is transmitted between secondary and primary care. When a patient is admitted it is easy for a clinician (or computer) to ‘convert’ a medicinal product prescription to a VTM prescription. But when a patient is discharged, automatically ‘converting’ a VTM to a medicinal product is almost always impossible – there are just too many options, too much ambiguity.

In the world of medicines digital interoperability, it would be a lot easier if everyone just prescribed medicinal products. If actual products are documented, data is easily shared. There would be no ambiguity, and digital systems could interoperate without the need for human intervention.

In my opinion, the solution is to ensure that when a patient is discharged from hospital, the discharge prescription only contains medicinal products. During the inpatient stay, hospital prescribers should be free to use VTM prescriptions on the inpatient drug chart, and work with their pharmacy and nursing colleagues to ensure safe and cost-effective dispensing and administration. But when a patient leaves hospital, if we want medicines interoperability, we need to prescribe products to remove the ambiguity.

Interneuron are delighted to be working with the PRSB to ensure the discharge summary standard supports medicines digital interoperability, and look forward to seeing the impact of this and other PRSB standards as they are adopted across the NHS.

Originally written for and published by the PRSB: Medicinal product or molecule? – PRSB (theprsb.org). The challenge for medicines...

Medicinal product or molecule?

The proper management of a patient's fluid balance is a fundamental element of delivering safe and effective care and is all too often ignored by digital system providers. Interneuron’s Fluid Balance module has been developed in close liaison with clinicians and nurses to ensure comprehensive functionality managing both routine and complex (infusion) fluid inputs and outputs.

Fluid Balance

Accurate 24 hour fluid balance monitoring is essential in the prevention and management of Acute Kidney Injury (AKI) as well as the routine management of post operative patients. 

Safe prescribing and inpatient medicines administration of NHS standard dm+d medicines. We support supply requests, medicines reconciliation and reminders.

openEPMA

The Discharge Summary Module simplifies the inpatient discharge process. Taking data from openEPMA and the Handover Module, it auto-populates the first draft of the discharge summary allowing the discharging clinician to review, edit and authorise a safe discharge.

Discharge

The Medicines Management Console (MMC) gives your pharmacists complete control over the medicines and prescribing options within openEPMA. The MMC supports dm+d by default, but allows the addition of new research therapies, default warnings, reminders and endorsements.

Medicines Management

Knowing where your patients are and how they move though your organisation is essential to the efficient running of any healthcare organisation. The Patient Flow Modules allows you to see and monitor patients in real time from admission to timely discharge.

Patient Flow

Our Observations Module is based on the Royal College of Physicians NEWS2 scoring design. We have extended it to support PEWS and it can be easily configured to support  bespoke scoring systems as required. We have worked with NHSDigital on the new National PEWS scoring system.

Observations

The flexibility in our Assessments Module is incredibly powerful. We support both clinical and administrative assessments (e.g. VTE and nursing risk assessments), pre-populating data that has already been entered before and capturing new structured data where necessary.

Assessments

Keeping up to date with the most recent changes to inpatient care is especially important during handover. Our Handover Module provides a summary view of your inpatients, that can be updated in realtime, supports task management and SNOMED clinical coding.

Not all platforms are equal

Common and extensible data model

Open and extensible APIs

Insert-only data persistence

Date

Author

Share

Recent Posts

Keep your options Open

Interneuron Modular Care Record

Medicinal product or molecule?