Noam H. Arzt, Ph.D.The development and acquisition of public health systems is poised to change. Historically, public health agencies had the classic choice when it came to acquiring a new data system. Either they developed the system themselves – usually based on a belief that their requirements were “unique” – or they licensed a COTS/GOTS product from the limited choices available in a small market.
Typically, agencies that chose to develop solutions were forced to use a waterfall approach as government procurement is not well suited to the flexibility of Agile systems development. Some agencies have been able to leverage open source offerings. While most do not have the wherewithal to support open source products themselves, many have formed strong partnerships with other organizations, both for-profit and nonprofit, to take advantage of these systems.
The software market in public health has always been somewhat limited, and has become even more constrained in recent years. In some cases the Centers for Disease Control and Prevention (CDC) has paid for the development of software that could be used freely by any agency. A good example of this is the NEDSS Base System (NBS) developed by an outside vendor but distributed and still supported by CDC. But NBS does have commercial competitors, like the Maven Disease Surveillance & Outbreak Management System developed and supported by Conduent.
In the Immunization Information System (IIS) domain, there are strong vendor offerings by Envision and STC, as well as a shared product developed by the State of Wisconsin Immunization Registry (WIR) and supported by several vendors that are widely used. Recently, CDC funded the development of a successor product to WIR which will be available to any jurisdiction that chooses to use it. More recently, CDC deployed the Vaccine Administration Management System (VAMS) in a cloud-based environment for use by jurisdictions and Federal agencies for COVID pandemic response.
Additional choices have grown out of specific public health implementations. Altarum, for instance, developed a disease surveillance system for the State of Michigan which it now offers as an open source solution to others. HLN developed its Immunization Calculation Engine (ICE) originally with the NYC Department of Health and Mental Hygiene and together they released it as an open source evaluation and forecast product that HLN supports.
Johns Hopkins University originally developed the Electronic Surveillance System for the Early Notification of Community-Based Epidemics (ESSENCE) with support from the State of Maryland more than twenty years ago and it has now been adopted more broadly by CDC in its national syndromic surveillance program.
As in many industries, there has always been a tension between the desire to have an application that works exactly the way the agency wants, and the desire to implement more affordable solutions that do not require much customization. Public health agencies have experienced this tension firsthand, having to choose one over the other. Over the last ten to twenty years installed systems have aged and their architectures have become outdated. Whereas it was once common for a system to be deployed on a dedicated server in an agency-run or outsourced data center, these systems have begun to migrate to public or private cloud environments.
While this “lift and shift” strategy has changed the cost basis for system operations, improved system and network resilience, improved performance and in many cases reduced downtime, it has not fundamentally changed the way systems are developed or function from the user’s point of view, and does not support the time-sensitive and rapidly changing requirements we have experienced more recently.
So what do we expect to change in the next few years? Systems will either be rearchitected or completely replaced with new options that more natively leverage cloud computing strengths. Systems will become more modular, enabling the substitution of one component for a better/enhanced one in the future without replacing the whole system. Systems will be comprised of “services” which can be scaled (up or down) based on their evolving requirements and easily configured or reconfigured in different ways. Implementations may share common components but be assembled differently to more closely fulfill specific user requirements. Some services may be run external to the agency, changing the nature of system operations. This may also precipitate a shift from budgeting capital costs (traditional system acquisition) to operating costs (pay-as-you-go services). Open source components will become more feasible in this type of environment, lowering cost and increasing creativity.
For agencies, this will necessitate a change in procurement practices: from lowest cost to best value; from fixed-price or deliverables-based projects to challenge-based procurement; from monolithic, COTS systems to modular and open source; from waterfall development techniques to “finish” a system to continuous development and Agile methodologies. The CDC’s Data Modernization Initiative (DMI) is preparing agencies to think in these terms. The Northstar Architecture is a roadmap for building systems with these attributes.
Agencies will face many challenges including bureaucracies that are rooted in older ways of doing things, a labor market that may require different skill sets, and the fear that current and emerging funding driven by pandemic response will not be sustained long enough for meaningful change. We are at a point where technology is capable of delivering more modular and configurable solutions, but need agency policies and workforce to be positioned for imminent change.
This post was authored by Noam H. Arzt, and first published in the HLN Blog. It is reprinted by Open Health News with permission from the author. The original post can be found here.
