Table 1.

Global good maturity model 1.0 guideline of digital intervention tools containing 15 subindicators from global utility, community support, and software maturity global indicators.

Indicator		Low	Medium	High
Global utility
	Country utilization	Less than two countries or states actively use the tool for use as part of their health information system	At least four countries or states actively use the tool for use as part of their health information system, with at least 20% of total nation-wide or state-wide target users routinely using product or service as intended	At least ten countries or states actively use the tool for use as part of their health information system, with at least 30% of total nation-wide or state-wide target users routinely using product/service as intended
	Country strategy	Less than two countries or states have included the tool as part of their electronic health (eHealth) strategy or framework	At least four countries or states have included the tool as part of their eHealth strategy or framework	At least ten countries or states have included the tool as part of their eHealth strategy or framework
	Digital health interventions	The tool does not meet digital functional requirements (as defined by World Health Organization’s [WHO’s] Classification of Digital Health Interventions) without significant customization or configuration	The tool does partially meet digital functional requirements (as defined by WHO’s Classification of Digital Health Interventions) without significant customization or configuration	The tool does fully meet digital functional requirements (as defined by WHO’s Classification of Digital Health Interventions) without significant customization or configuration
	Source code accessibility	Source code not publicly available or not released under an open-source license	Source code exists on a publicly accessible repository and licensed under an open-source initiative approved license	Source code exists on a publicly accessible repository and licensed under an open-source initiative approved license. The software is structured to allow local customizations and new modules and functionality without requiring forking of main code
	Funding and revenue	At most, two revenue streams exist. Revenue streams are largely dependent on time-bound project implementations	Multiple revenue streams/funders exist across project implementations	Multiple revenue streams and funding mechanisms exist, including at least one that provides for multi-year support of core software development, documentation, and other key artifacts
Community support
	Developer, contributor, and implementer community engagement	Less than 10% of the estimated total of developers, contributors and implementers are on a communication platform	Up to 20% of the estimated total of developers, contributors, or implementers, including some country representation, are engaged on a communication platform	At least 30% of estimated total developers, contributors, and implementers are engaged on a communication platform. Community leadership includes representation from countries where the tool is deployed
	Community governance	There is no community governance structure in place to direct continued development of the digital health tool	Some informal processes for community management exist to direct continued development of the digital health tool	Formal community structures (eg, leadership, technical advisory group, and community representatives) exist and are practiced with documented roles and responsibilities in a transparent fashion and are used to direct continued development of the digital health tool
	Software roadmap	No software roadmap exists, or there is no publicly accessible and routinely maintained platform for new feature requests	There is a publicly accessible and routinely maintained platform for new feature requests. A software roadmap exists describing currently planned and resourced development activities	New features and functionality are documented as part of a software roadmap as part of a release cycle. There are forums for community members to discuss new feature requests. A clear prioritization process exists and is utilized for the development of new features and functionality as part of a product backlog
	User documentation	No user documentation exists	Some user documentation exists (training manual, demo videos) but only addresses a limited subset of common functionality	A full suite of user documentation exists, including training manuals, web-based courses, tutorials, and implementation guides addressing most of the common functionality. Documentation has been released under a Creative Commons license
	Multilingual support	Limited or no support in the software for multiple languages. Multilingual documentation/user resources are practically nonexistent	Software has been internationalized to support multiple languages (though may not have been translated) for primary portions of the user interface. Some user documentation exists in more than one language	Software has been translated into multiple languages and fully supports internationalization requirements. There is an easy tool for new translations to be added. Significant parts of user and implementer documentation has been translated into at least one other language
Software maturity
	Technical documentation	No substantial documentation of the software exists	Some technical documentation exists of the source code, use cases, and functional requirements	Source code is documented to the point that new adopters can customize and add new functionality with relying on significant help from one of the core developers. Online courses or tutorials are available to address common development and deployment tasks. Core business workflows and functional requirements are fully documented using use cases, user stories, or other equivalent methodology
	Software productization	No documentation available for deployment and configuration	Full documentation available for deployment and configuration. A new implementation does not require the involvement of the core development team	Software has been packaged for one or more common operating systems or platforms. Software upgrades can largely be achieved without manual intervention. Unit or integration testing is part of the release process
	Interoperability and data accessibility	Extract or import data into the system usually requires looking at source code and/or directly accessing database	Some application programming interfaces (APIs) are available for accessing and managing data. There are user-facing interfaces to export core data and metadata in the system (eg, in CSV format) for further analysis and data transfer purposes	A robust API is available for key data and metadata exchange needs for the primary business domain with functional requirements for the API having been developed in conjunction with appropriate country, regional, and global stakeholders. API endpoints exist for core data and metadata elements that adhere to standards developed by an appropriate Standards Development Organization relevant to the tools business domain. Standards-based API endpoints are used in at least four jurisdictions (eg, countries or states)
	Security	No security controls or implementation guidance is in place	Role-based authorization exists, if appropriate. Guidance on encrypting all remote access (web interface and APIs) is available to implementers	Role-based authorization exists, if appropriate. All remote access (web interface and APIs) are encrypted by default using current best practices. An independent security audit of the software has taken place within the last 12 months
	Scalability	There are no jurisdictions (eg, country and state) that manage 10% of their “entities” within the tool, and no performance and load statistics exist	There is at least one jurisdiction (eg, country and state) deployment for which 20% of all “entities” are managed within the software. There has been at least one evaluation of software performance/load testing	There is at least one jurisdictions (eg, country, state) deployment for which 30% of all “entities” are managed within the software. Performance and load testing is a part of routine releases, and results are publicly available