Sepsis and septic shock are major health concerns, especially in children. Children account for half of global sepsis cases and one third of sepsis-related deaths—emphasizing a large need for research on the diagnosis and treatment of pediatric sepsis.
Peter DeWitt, PhD, assistant research professor of biomedical informatics at the University of Colorado Anschutz (CU Anschutz), conducts research on pediatric sepsis.
In 2022, DeWitt joined a research task force organized by the Society for Critical Care Medicine to develop and validate criteria for sepsis and septic shock in children. The updated criteria was published in 2024 to improve diagnosis of pediatric sepsis across the world.
Since the criteria have been published, DeWitt has continued to iterate and refine pediatric sepsis research. In addition to supporting the task force with the development of the criteria, DeWitt also developed the phoenix package: a software tool that allows researchers to implement the Phoenix Criteria consistently and repeatedly.
This is the third installment in our ongoing series spotlighting the DBMI Wall of Software, an interactive online hub showcasing the latest open-source software and data tools for researchers. View the Wall of Software here.
We sat down with DeWitt to better understand the phoenix package and its implementation.
What is the Phoenix Criteria?
The Phoenix Criteria is a data-driven system used to support diagnosis of sepsis and septic shock in children by evaluating organ dysfunction. This criteria helps researchers to better predict interventions and outcomes.
It looks at how well different organ systems—like the heart, lungs, and neurologic—are working. By combining this information, the score helps predict how serious the illness might be, and how likely the child is to recover. In short, it gives a clearer picture of the child’s overall condition so that care teams can make better decisions.
What is the phoenix package?
The phoenix package is a utility for applying the Phoenix Criteria for pediatric sepsis and septic shock consistently on data sets. The package was originally written in R, but there is also a Python module and some example SQL code available, as well. This makes the tool available to a wide range of researchers.
Why did you create the phoenix tool?
The initial reason for creating the tool was to streamline my own work. The phoenix package came after we published the phoenix criteria for pediatric sepsis. I was using these SQL scripts, and every time I ran the code, I had to redo the scripts for the analysis. So I built a tool so that I wouldn’t have to go through that process over and over again. But then I figured others would benefit from this tool as well, so I published it so that anyone could replicate it.
The benefit of building this tool is consistency. First, it assures there is consistency in my work. The tool assures that I’m applying the criteria correctly in every project that I’m doing; having a piece of reproducible and reusable code gives me certainty that I am applying the criteria consistently.
Beyond this, the tool also assures there is consistency in other researchers’ work. If I’m reading the literature, and I see that someone else has used the phoenix package, this tells me that they are applying the criteria and handling edge cases in the same way. For example, a data scientist in Vietnam could also have the same consistency in their work as me—just by using the Phoenix Package. This creates consistency across the literature.
Having one tool for calculating Phoenix also makes sure that “edge cases”—or rare situations that occur at the edge of a system’s expected operations—are treated consistently. For example, when calculating a child's mean arterial pressure (MAP), small differences in how numbers are treated can change the results. For example, with scoring on the Phoenix criteria, if the result was calculated as an integer (whole number), then the cutoff points of "greater than 30" for zero points and "17-30" for 1 point is correct and sufficient. But, if MAP is calculated allowing for floating-point values (decimals), then the “greater than 30” could cause errors because there are possible outcomes between 30 and 31. The software in the phoenix package removes any ambiguity from the organ dysfunction scoring rubric.
The phoenix package is freely available. The only prerequisites are R or Python, and the ability to read documentation (written in English).
What is the biggest impact of the phoenix tool? How does it help with patient health?
Related to the original publications in JAMA, we are working on other related packages. First, we are working on a mobile application to use the Phoenix criteria in the field. We are also working with a couple of sites to implement the Phoenix criteria into EHRs, and we are about to start research on phenotyping for sepsis and (hopefully) screening criteria in the emergency department.
In all of these cases, the code that was originally written for the phoenix R package and the phoenix Python module has been reused. It's laying the foundation for these other applications and use cases. And it goes back to consistency. If we use this package, we know how the criteria were applied to the data, and thus we can have some confidence that it was applied in a way we expected it to be.
How can someone access the phoenix tool?
The package is originally written in R, but there is also a Python module for those who might be working in Python, as well as some SQL code examples. The R package phoenix is available on the comprehensive R archive network (CRAN), and the Python module phoenix-sepsis is available on PyPI. The phoenix package can also be accessed through the DBMI Wall of Software, where the package’s documentation is linked.
