In the United Kingdom, as elsewhere, Healthcare IT is evolving at a rapid pace. With government targets and more local initiatives, organizations are looking for solutions that fully support their clinical processes, in an environment where each trust, health board, department, specialty, and even individual user works in different ways, no matter how subtle. Many organisations are using in-house developments in an effort to react more quickly and to support these differing processes, but there’s often a downside.
Having spent many years working with a range of different suppliers, I fully understand the frustrations of technical teams and end users who, when requesting a valid change, often technically minor but high impact, are greeted with a higher than expected quotation for development and/or a long lead time running into months when healthcare organizations are more and more often required to react with much more agility.
When I worked as the development manager at an National Health Service (NHS) trust, these issues were the reason our in-house development was so successful. Initially, we developed software to fill in gaps of existing commercial IT systems, or to support innovative process efficiency improvements using Lean tools. Our ability to react quickly and positively led to us being asked to develop further, to the point where in house was seen as the Holy Grail: no longer having to buy new systems, and even replacing existing systems to save on costs.
After several years as development manager, I had growing concerns about the robustness of in-house development processes. Software development isn’t the core business for the NHS and the cracks were starting to appear. This is what led to me finally leave the team to join Ideagen in 2014. The success of the team led to unnecessary pressure to go above and beyond what an under resourced team was capable of, but a drive to innovate and improve, along with the standard job preservation lead to a “yes” response every time. Critical processes such as support and testing were undervalued and project and development controls were difficult to implement.
I originally joined Ideagen as a pre-sales manager, and although it is still a massive part of my role, due to my previous experience, I found myself in front of a team of highly experienced developers in my first week on the job in the role of product manager who would guide them in creating a brand new clinical portal, along with supporting the ongoing development of all products in the clinical and content suite. I had confidence in my abilities to shape the product, but I had one big question burning in my mind: “How can I enable our customers to reap the same benefits we did as an in-house team while still ensuring robust commercial support?” The answer was obvious; the product needs to be highly configurable, not only by Ideagen during implementation and beyond, but for customers’ own technical teams to allow them to respond in a much more agile way by configuring the product’s user interface and features themselves, with full support from Ideagen.
One of the reasons for getting to a product which is so configurable and scalable was my stock response to a lot of questions raised by the team back in the early days. When asked how particular things should work, I responded, “Make it configurable by the customer.” Very soon, the team learned that every setting, feature, tile, and viewer had to be fully configurable to enable customers’ technical teams to respond positively to requests from their clinical colleagues and make changes themselves – fully supported by Ideagen where required.
Customers using the Ideagen Clinical portal are very vocal about the unique benefits of the product, where their in-house teams have taken the configuration delivered to them during implementation, and modified and built additional features and integrations using our highly configurable open application development framework. This has led to happy IT departments, and, more importantly, happy clinicians who, rather than have to modify their working practices to accommodate an IT system that is static, have a system that can be tailored by their local IT team, and configured by themselves to display the information that is most relevant and useful for them.
About the author: Paul Jackson has more than twelve years experience in the NHS in various roles, from support and project management through to software development management. As a senior product manager at Ideagen, Paul’s job is to act as a product champion and to gather and understand customer requirements to ensure Ideagen’s clinical products remain at the cutting edge and exceed the requirements for existing and potential clients.
