Accelerating innovation in healthcare using low-code development
At Better, we want to improve health and care by simplifying the work of health and care teams. We believe there is an opportunity to accelerate digital transformation in healthcare and everything we do is underpinned by a philosophy that data is for life.
One of the technology components we are working on to enable this vision is our low-code platform. This post is my take on low-code and a proposal to make part of that more open.
What is low-code?
Low-code is an emerging trend in the world of software development. Low code platforms provide a visual way to build applications using pre-coded drag and drop components — ranging from simple things such as text boxes through to more complex things like graphs or connectivity to external APIs.
The group of people who use low code platforms are typically referred to as “citizen developers”. Often they are non-programmers, but with a user-centred, analytical mindset that is aligned with understanding and solving complex problems.
I believe we are entering the next generation of software development where low-code platforms will become the default way to deliver enterprise applications —which in the past has typically been reserved for the enterprise IT department or the professional developer.
Gartner shares a similar view. In their “Top 10 Application Predictions Through 2025”, they predict;
“By 2025, 70% of new applications developed by enterprises will use low-code/no-code technologies”
Why is this happening?
Because low-code platforms enable accelerated speed of delivery and reduced total cost of ownership.
From our experience, the overall size of a delivery team for a complex project is approximately half the size of a traditional “high-code” delivery, with the overall delivery being completed approximately 2–3 times quicker.
The team profile needed for a low-code delivery will obviously vary depending on the problem being solved, but will still typically involve many familiar roles, including architects, delivery managers and product managers. However, you will often eliminate the need for professional developers – who are notoriously expensive and difficult to recruit.
Finally, as a whole, the team engagement will move higher up the value chain so teams are focused more on understanding user needs and less on managing infrastructure and associated software artefacts. Anything that does this is a good thing in my view.
However, in healthcare adoption of low-code has been limited. One of the biggest challenges – in my opinion – has typically been dealing with the complexity of healthcare data, which constrains all but the simplest of use cases.
At Better, we have addressed this challenge head-on.
We are working on a low-code platform (called Better Studio) that has been designed from the ground up to specifically support citizen developers working in healthcare. Everything we do works up from the openEHR models that are being used within a particular environment. This is in contrast to many tools which start with the UI and then work back to the data, creating many challenges including those around data management, governance and sharing.
This approach may work in other industries but in healthcare, the complexity of data and the need for data longevity necessitate a data-first approach that is based on a robust modelling framework. For more details on the importance of this —and specifically the adoption of openEHR – check out my previous article, Why openEHR is Eating Healthcare.
We see a world where citizen developers are able to quickly and easily solve complex healthcare problems in a way that is not only simple to use for end-users but is safe, secure and compliant.
To support this, we have established a design system to ensure that all the forms and applications created by citizen developers follow a defined set of patterns for how they behave and how they look. This consistency helps to reduce the training needs for end-users and ensures they are delivered in line with patient safety requirements. Check out the video below for an overview.
We also want low-code development to involve as little code as possible — ideally, none — allowing citizen developers to focus on solving the problem at hand without having to worry about custom scripting and the impact this has around testing, maintenance and compliance.
However, we also acknowledge that the problems our customers have are often complex and can go beyond the parameters of any low/no-code tool the market can offer.
To address this we have designed Better Studio according to a micro-kernel architecture style.
This is a relatively simple architecture comprising of two key components — a core system and plug-in components. Application logic is divided between independent plug-in components and the core system, providing extensibility, adaptability and isolation of application features and custom plug-in logic. The diagram below illustrates the basic idea of this architecture.
When we encounter a situation that cannot be solved with out-of-the-box tooling we first look to build a plug-in, not to write custom code that is embedded in the form or application. A plug-in could be used to support things like a dashboard, a graph, an entire form, or a clinical algorithm.
However, we don’t want to become the bottleneck in the process of creating plug-ins so we would like to establish some standards around what a plug-in is and how it behaves. We hope this will allow a community to emerge where customers, partners and third parties create reusable plug-ins that can be shared.
One of the main types of plug-in we currently support are “Widgets” — an exciting new feature we have recently launched. Check out this video for a quick preview of how Widgets can be built and shared.
Widgets are Web Components that will run in any browser, using any web application framework and on any openEHR repository. On our roadmap, we have lots of ideas for exciting new Widgets we plan to build, but more importantly, we would love to see a community emerge where anyone can build a Widget or re-use one that has already been created.
Where Archetypes and the supporting community are the secret sauce of openEHR, we believe Widgets — and the wider concept of open, re-usable plug-ins — will do the same for low-code development in healthcare.
To facilitate the distribution and sharing of clinical content we have created an online environment we call Marketplace. This will soon be rebranded to Clinical Content Manager to remove any commercial connotations, but the idea remains the same — to allow clinical content to be published and shared.
To achieve this we have made the specification for Widget development open.
Check out our proposal for this at the link below.
This proposal is currently Alpha, so we would love feedback to ensure we can iterate our approach and refine it in a way that supports the wider needs of the community — and importantly— that we deliver another building block to enable low-code to truly accelerate innovation in health and care
Please get in touch with me or any of the Better Studio team if you would like to contribute.
Thanks for the contributions and review from Boris Marn – Better Studio lead.
