In order to ensure that Global Goods and Digital Public Goods can enable impact without doing any harm, it is crucial that their authentication and authorization systems are secure from the outset.

We’ve put together a resource to help other Digital Public Goods and Global Goods achieve just this.

You can view and comment on the resource here, or read on to learn why.

Digital health technologies have a critical role to play in both improving the delivery of health services and making health systems more robust and adaptable. Whilst this has been the consensus for a while, various factors such as bureaucracy, lack of capacity, authority/ownership, budget or simply lack of prioritization have hindered the adoption and implementation of such technologies.

However, the COVID-19 pandemic has brought digital health systems back to the top of the agenda, having forced governments to adapt their health systems and processes in a short amount of time and confronted them with the fragility and inflexibility of some of their existing systems. This has led to an increase in funding for both new and existing health technologies.

At the same time, the recent pandemic also saw an increase in data breaches and data leaks in the healthcare sector. Whilst these are a serious matter in any system, the nature of the healthcare technologies means that the data they are storing or managing almost always includes Personally Identifiable Information (PII) which, if leaked, can have dramatic consequences for those they identify.

The higher the number of technologies and quantity of data stored in these, the higher the risk of vulnerabilities and negative impact of a data breach or data leak. If Global Goods are to make the most of this renewed interest and increase in funding for digital health technologies, it is crucial for them to keep security as a top priority to ensure that they ‘do no harm’, a core Digital Public Good principle.

Several organizations have already put some thought into documenting security best practices and standards. However, none situate these security decisions within the wider context of a product development timeline or roadmap. This requires individuals to regularly scan through long lists of security recommendations to pick out and prioritize their implementation, increasing the likelihood of an oversight or early-made product decisions which make it harder to implement such security features down the line.

As product manager at Open Function Group, I myself have recently been reviewing and analyzing numerous resources to identify and prioritize features required to get to fully-secure authentication and authorization for our newest product Lightning–and make sure that nothing falls through the cracks. I’ve also had the opportunity to gather insights from Digital Public Good community forums (OpenMRS, DHIS2, OpenLMIS, etc) and speak to other product managers and engineers from the Digital Public Goods community to ask them about their learnings, and any tips they might have: Austin and Morten from DHIS2, Dev and Biyeun from Dimagi.

To more widely share these learnings, we have drafted this resource documenting the specific security measures that should be considered at each stage of product development specifically with regards to authentication and authorization. Our hope is that this article will help other product managers in the Global Good (GG) and Digital Public Good (DPG) communities consider these features into their backlog/roadmap from the outset and make sure they are following a ‘secure by design’ approach. To inform our analysis, we analyzed learnings from the wider DPG community, as well as recommendations from other security experts and international standards, including GovStack, OpenHIE, OWASP, NIST, and more.

The resource can be found here.

Do you think twice when you get an automatic SMS notification because your prescription is ready? (Neither do I.) This seamless experience is driven by “workflow automation”, a key feature that OpenFn provides. The OpenFn Integration Toolkit is a Digital Public Good (DPG) used by governments and NGOs to boost efficiency through workflow automation. The automation that OpenFn provides includes automatically sending SMSs, automating stock updates across supply chain systems, tracking clinical visits, and helping plan vaccine rollouts. We support our partners’ work by lifting the burden of manual data transfers between platforms.

OpenFn automation happens via jobs which define specific steps ("operations") that OpenFn should perform. They're written in a scripting language that runs on top of (and has full access to) Javascript. A basic understanding of Javascript will take your job writing on OpenFn to the next level. To improve my limited knowledge of JavaScript, I have been taking Codecademy's Introduction to JavaScript Course.

Have you ever struggled to layout the strategy for testing your React App? Well, you are not alone! Here a few hints from the lessons I learned during my experience testing a React/Redux app with a Phoenix/Elixir backend.

We're very happy users of Elixir and Phoenix at OpenFn, given that we've been using it continuously for about 6 years - upgrades and all. Our front-end toolchain, albeit far from out of date (Webpack 5.52.1 today) has left some room for improvement.

So you're using docker's multi-stage builds and noticed that your build times aren't nearly as quick as you expected?

Jobs are business processes turned into functional-style scripts. What does that mean, how should you approach writing jobs?

This is a quick one, but I just got off an exciting call with an organization that's going to set up some jobs to move data into Salesforce from CommCare and realized that despite this being one of our more common integration requirements, we haven't done a 'tips' article for this type of project. Until now.

“Syncing” is getting two systems to a state of harmony. This might mean keeping a list of patients up to date, though modifications can be made in either system. It might mean copying transactions from one system to another on a nightly basis. It might mean a lot of things, but the key concept is that when you sync systems, you’re asking them to work together while simultaneously respecting both software systems’ independence.

In this post we’ll discuss two different syncing protocols to consider when designing your data integration. These include:

1. Real-time, or event-based, syncs
2. Scheduled syncs

Zandile is a program manager at an iNGO and she needs to use CommCare, DHIS2, and OpenFn for an upcoming public health project. She understands that all three pieces of software can be deployed locally, or accessed as SaaS (Software as a Service).

Essentially, Zandile needs to decide if she would like to run the software on someone else’s servers (SaaS), or on her organization’s own servers (deployed locally). Before making a decision she outlines the basic, non-technical considerations for both options.