Digital Health Software: Global Good Maturity Model - v1.1

	A	B	C	D	E	F
1	core indicator	sub-indicator	Global Good Maturity Model for digital health software tools. Version 1.1
2	core indicator	sub-indicator	Low	Medium	High	Notes
3	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/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
4		Country Strategy	Less than two countries or states have included the tool as part of their 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
5		Digital Health Interventions	the tool does not meet digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration	the tool does partially meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration	the tool does fully meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration
6		Source Code Accessibility	source code not publically 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. Software is structured to allow local customizations and new modules and functionality without requiring forking of main code
7		Funding and Revenue	at most two revenue streams exists. 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.	a revenue stream indicates a source of funding to support the development of a global good. such revenue streams could come from donor contributions, from one of the variety of business models used by open source software tools to fund their continued development, or from in-kind contribution from an organization
8	Community Support	Developer, Contributor and Implementor Community Engagement	Less than 10% of estimated total of developers, contributors and implementers are on a communication platform	Up to 20% of 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
9		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 (e.g. leadership, technical advisory group, 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
10		Software Roadmap	no software roadmap exists or there is no publicly accessible and routintely maintained platform for new feature requests	there is a publicly accessible and routintely 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.
11		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, online courses, tutorials and implementation guides addressing most of the common functionality. documentation has been released under a Creative Commons license
12		Multi-Lingual Support	Limited or no support in the software for multiple languages. Multi-lingual documentation / user resources are practically non-existent	Software has be 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.
13	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
14		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.
15		Interoperability and Data Accessibility	extract or importing data into the system usually requires looking at source code and/or directly accessing database	some APIs are available for accessing and managing data. there are user facing interfaces to export core data and metadata in the system (e.g. 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 conjuction with appropriate country, regional and global stakeholders. API endpoints exist for core data and metadata elements which 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 (e.g. countries or states).
16		Security	No security controls or implementation guidance is in place.	Role based authorization exists, if appropriate. Guidance on encrypting all remote access (web interface, APIs) is available to implementors.	Role based authorization exists, if appropriate. All remote access (web interface, APIs) are encrypted by default using current best practices. An independent security audit of the software has taken place within the last twelve months.
17		Scalability	There are no jurisdicions (e.g. country, state) that manage 10% of their "entities" within the tool and no performance and load statistics exist.	There is at least one jurisdicion (e.g. country, 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 jurisdicions (e.g. 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.	Entities are the data objects that are central to the pimary business domain that the software addresses. For example, an EMR would have a patient as one of its entities.
18
19