Diabetes, Project - Building Data Applications That Actually Last

If you take a look around at this website, you'll notice that the focus of my work is on diabetes-related applications. This article is no different, but I think that these principles are applicable in a lot of different contexts.

To set a starting point, what data application are we talking about? Any that takes data of a diabetic patient, think glucose levels for example, and spits out some, allegedly, useful result.

If you want to skip to the example, go to the bottom.

I rambled elsewhere that the real problem to solve in diabetes-related applications is probably different from what most developers think, but here I want to focus on the specific characteristics that apps should possess from a technological implementation standpoint. In other words, what makes the difference between a piece of software that gets abandoned after a few months and one that becomes an integral part of healthcare workflows for years to come?

Why This is Such a Complex Problem

There's a fascinating dichotomy in the technical requirements that makes development particularly challenging. On one hand, these applications must be extremely flexible due to the high degree of heterogeneity among the healthcare professionals they serve. Every endocrinologist has different preferences, every clinic has unique workflows, and even individual doctors treat vastly different patient segments with distinct needs.

On the other hand, we must simultaneously meet high security standards, comply with frequently changing legal regulations (think HIPAA, GDPR, and countless regional variations), and remain profitable in order to keep being able to develop and maintain. This creates a technical puzzle where traditionally opposing forces in software development must coexist.

The Necessary (But Not Sufficient) Criteria for Development

1. Rapid Customization

The application architecture must support fast customizations including visualizations, UI interfaces, and various input methods for each client. Different doctors don't just have different preferences - they often treat completely different patient populations within their own practice. A pediatric endocrinologist managing Type 1 diabetes in teenagers has vastly different needs compared to a geriatrician handling Type 2 diabetes complications in elderly patients: the questions they ask the data are different.

The technical implications are profound. If modifying a visualization, adjusting user interface elements, or adding/removing small functionalities requires a software development cycle that spans weeks or months before release, the application simply cannot keep up with real-world demands. Instead, what generally happens when the release cycle is slow, is that most applications try to appeal to as many people as possible, thus diluting the efficacy of the solution that they can provide to each specific need. The development process must be architected from the ground up to accommodate these rapid iterations as a core feature, not as an afterthought.

2. Flexible Data Format

Applications must be able to deal with diverse data formats, types, and frequencies. One patient category may have detailed insulin usage records captured from continuous glucose monitors and smart insulin pens, while another group might only have periodic manual blood glucose readings and paper-based food logs.

The application's data ingestion layer must be robust enough to handle this variability without breaking or requiring extensive reconfiguration. This means implementing flexible data schemas, robust parsing mechanisms, and graceful degradation when certain data types are unavailable. Also any analysis must be either able to account for different data and missing data at the same time, or must be worth implementing for just a specific use case.

3. Deterministic and Verifiable

It is not always possible, but an ideal analysis tool's purpose should be twofold: first, to highlight interesting patterns that wouldn't be detectable through manual review of raw data, and second, to provide healthcare professionals with the ability to interrogate these patterns to understand their underlying dynamics more deeply.

The analysis process must be completely transparent, there should be no ambiguity in interpreting results or understanding what any method of interrogation does. This is particularly crucial in healthcare where "black box" solutions, despite their sophistication, often fail to gain trust among practitioners who need to understand and justify their clinical decisions. Transparency often matters more than sophistication.

4. Integration and Privacy

If your application needs to talk to a lot of different other software in a rigid way, you are asking for trouble, especially because, in any reasonable structured medical practice, you are going to deal with software that is easily at least 15 years old, if not more.

5. Evaluating Vendor Lock-in Carefully

Connected to the previous point, navigating the technology landscape requires careful consideration of often-invisible costs related to infrastructural choices. Should you manage your own database separately? Should you rely on cloud hosting solutions?

6. Economic Maintainability

The variety of potential healthcare professionals is vast, and continuous cash flow isn't always achievable. For individual doctors or small clinics, there's a risk of having substantial work requirements with limited revenue potential. For contracts with large hospitals or medical groups, while they generally provide better margins, they come with different complications and sales cycles that can last months, making it difficult to maintain steady cash flow between contracts.

From a technical perspective, this means the application architecture must be designed for efficient maintenance: automated testing, auto-generated documentation, modular design, and minimal technical debt. The cost of adding new features or adapting to new requirements must remain predictable and reasonable. It is more important to be able to absorb periods of low revenue while keeping offering support to currently active deployments rather than gamble all your revenue over an exciting new feature.

All the planets must be aligned

In my experience, all these factors must be present simultaneously to have any hope of success in this domain. Miss one, and the entire initiative becomes unsustainable, regardless of how well you execute the others, but practical solutions to all these problems do exist.

Success in this space requires both leveraging industry-wide technological advances and developing organization-specific capabilities that can navigate the unique challenges of healthcare technology deployment.

Industry-Wide Technological Enablers

Some help is provided by the technology industry as a whole, independent of any single organization's efforts. Consider the ability to run applications locally on professionals' computers without any server connection - this improves privacy, security, and integration ease simultaneously. Or the possibility of distributing web applications instead of native ones, which dramatically reduces development time and costs.

Overall hardware improvements and the consequent increase in browser performance, for example, have enabled many innovations that simply weren't feasible just a few years ago. Modern browsers can now handle complex data processing, sophisticated visualizations, and even machine learning tasks that previously required server-side processing.

Organization-Specific Solutions

Other solutions fall within the domain of individual organizations. Choosing to focus on a leaner development processes is a valid business choice. Individual companies can distinguish themselves by creating methodologies that try to accommodate extremely diverse needs, some of which we've seen above.

In this context, talent becomes fundamental in finding solutions that are increasingly flexible and economical while also being secure and effective. This is where technical expertise, domain knowledge, and creative problem-solving converge to create truly sustainable solutions.

An Example

Say that a doctor or a group of clinics want to analyze CGM data (glucose measurement taken every 5 minutes) in a specific way that is not made available from other vendors. Fair enough, this application is not dissimilar from a somewhat advanced dashboard. Now let's add some constraints to make things more interesting.

• Performance at least comparable with that of similar services: if professionals are using service A, service B cannot be 10 times slower.
• Privacy, adherence to legislation and security: let's assume that the legal team has not produced an extensive requirements list yet, how can we be reasonably sure to implement compliant software?
• Different UIs: each doctor wants a slightly different UI depending on the type of diabetes or treatment regimen that the patient is following.

For this example, we’ll limit our implementation to display information about the Time in range and hypoglycemic events of a patient that uses CGM monitoring.

Here is the demo.

Let's go through each criteria to see how our demo satisfied them.

1. Rapid customization: we choose a component based architecture, in our example the Streamlit library. There are many other similar tools.
2. Flexible Data Format: part of the flexibility comes with using well tested libraries like Pandas that can help to correctly manage missing data, timestamps and even visualization. Other visualization tools can create almost automatically different plots given different preferences or data availability. The other aspect of flexibility has to do with logic that is context dependent: for that there is no tool.
3. Deterministic and Verifiable: Since we're asked to provide only visualizations, and not any kind of prescriptions, we can provide different plots based on well known metrics in the literature and stay away from more complex methods. This approach is both easily verifiable and completely deterministic.
4. Integration: Our stack does not enable us to create a fully client-side only application but, assuming that the medical structure uses a third party solution for storing patient data, we can deploy our app directly on the client server. This pattern, quite common in this industry, makes it possible to keep the data inside a single clinic's server. If the server is already configured to adhere to privacy and regulatory requirements, we can be reasonably sure to be able to deploy software that is compliant.
5. Evaluating Vendor Lock-in Carefully: Our example stack is fully open source, so vendor lock-in is not present. The main external dependency could be represented by the connection to the database from where we fetch our data. If direct API integration isn't suitable, we could provide an alternative: CSV file uploads. Since nearly all diabetes data platforms allow users to export their data as CSV files, this approach would offer a reliable alternative method for importing patient data without being tied to any specific API or proprietary format.
6. Economic Maintainability: How do we make this profitable? This is highly dependent on the particular skills of the development team, but in this specific example: using a single language for the front-end and the back-end will make development somewhat faster. Also using pre-made components for almost anything will allow us to spend significant development time only where the customization makes sense. Also creating a single app for each clinic it is, up to a point, way easier to test, maintain and deploy then creating a big monolithic software that has to adhere to a vast spectrum of requirements and has to be tested under a very high number of permutations of features, environments, customizations etc.

Bonus: having a quick development cycle means that you can get a first working draft of the application so fast that, when the difficult decisions have to be made later in the project, both you and your client will have more hands-on experience, thus making the difficult decisions easier

Thank you

As always, thank you for your time.

If you want to send me something, XY at gmail.com where X = tommaso and Y = bassignana, no dots between X and Y. I'm always interested in hearing different perspectives and I respond to every email ;)