Low-cost Aplication Platforms (LCAP): What They Should Mean to Public Health

Noam ArztAgency budgets continue to run tight, while the demands for data modernization continue to escalate. We are also seeing weakening markets – not strengthening markets – for core public health software systems like Immunization Information Systems (IIS) and Disease Surveillance/case management systems. One of the emerging, promising approaches are Low-cost Application Platforms (LCAP). What exactly are they, where did they come from, and are they a useful strategy for developing core public health applications?

The computing industry has always strived to find lower effort approaches to software development. This has been driven to drive down both the cost as well as the time to deliver and maintain software applications, especially as software became “mission critical” to many businesses. Some of these desires have centered around finding alternatives to conventional computer programming that uses traditional programming languages. Those of us who have been around long enough remember earlier promises of Computer-Assisted Software Engineering (CASE) and Fourth Generation programming languages which only had limited success in liberating companies from highly-skilled software developers.

LCAP offers non-developers (so-called “citizen developers”) as well as professional programmers a more rapid way to develop software, even mission-critical applications, without the need to write conventional code. Through the use of drag and drop tools supported by sophisticated process mapping and flexible data models, LCAP promises faster application development at lower overall cost. Increasingly, LCAP will leverage artificial intelligence (AI). Over the next few years, the Gartner Group sees the use of LCAP continuing to increase steadily with more and more users located outside of the traditional IT departments (see also this Computerworld article). Leading tool providers in this space include Mendix, Microsoft, OutSystems, Salesforce, and ServiceNow.

At HLN, we specialize in creating core public health applications to support mission critical public health activities. We rely on traditional programming frameworks in an open systems environment; these days that typically means open source tools like React for front-end applications, and Java Spring for backend development, though these frameworks choices usually need to be revisited every few years as tools mature and change. Our style of development is usually Agile versus Waterfall. Increasingly, we leverage a microservices architecture often deployed within the open source Kubernetes environment to ensure scalability, performance, and resilience.

Our experience with our public health clients has been that they want a lot of control over how applications look and behave. Even off-the-shelf solutions that are targeted specifically for the public health market are often expected to have significant levels of customization for a particular agency which often defeats the purpose and benefit of an off-the-shelf solution. In the long run, it should be about building applications that meet your needs, and using other people’s applications when they are good enough.

Software development strategies involve trade offs. To use LCAP successfully – at least with the state of the market today – requires accepting applications that have a consistent (and often “basic”) look and feel. While they can be developed by individuals with a wide range of skills, including even non-programmers, the tools may promote “short cuts” in one’s approach to system design, architecture, security, and flow. The strength of LCAP is that applications can be developed rapidly by non-developers; this, however, can also be its most pressing weakness. Remember, also, that some LCAP environments can bring substantial cost for acquiring or accessing the tools, and many of the leading platforms are only offered as online services with ongoing fees.

While we have our doubts that LCAP environments in their current state will meet public health’s needs for core applications, we do believe that we can learn from the LCAP experience and optimize our approach to take advantage of the best that an LCAP philosophy has to offer:

  • Embrace modularity: Use a “building block” approach to assemble complex systems from available components; build new components only when you need to. Microservices help to make this possible in a reliable way.
  • Accept continuous development: Accept the notion that modern systems are never “finished.” Certainly we saw through the COVID-19 pandemic how needs changed, often in real time. Agile methodologies help here.
  • Leverage best of breed tools: Even without relying on a complete LCAP solution, many benefits of LCAP can be acquired in more specialized toolkits, like PowerBI, Tableau, or the open source Grafana for business intelligence and visualization; JasperReports for standard reporting; open source HAPI for FHIR and HL7 interoperability. This type of “best of breed” approach can be powerful; open source alternatives can make this more affordable.
  • Shift to modern cloud-based technologies to automate the building, testing, and deployment of software: Even for public health agencies with “on-prem” infrastructure, cloud services such as container registries, and open source software such as Kubernetes for container orchestration, can help reduce costs and shorten development cycles. 

This combination of techniques should result in lower-cost applications without sacrificing the quality, precision, or functionality that most agencies desire.

This post was authored by Noam H. Arzt, and first published in the HLN Blog. It is reprinted by Open Health News with permission. The original post can be found here.