ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
Core IndicatorSub-indicatorGlobal Good Maturity Model for digital health software tools.

Version 1.3
2
LowMediumHigh Notes
3
Global UtilityCountry UtilizationThree or less countries or states actively use the tool as part of their health information system At least four countries or states actively use the tool 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 intendedAt least ten countries or states actively use the tool 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 StrategyThree or less countries or states have included the tool as part of their eHealth strategy or frameworkAt least four countries or states have included the tool as part of their eHealth strategy or frameworkAt least ten countries or states have included the tool as part of their eHealth strategy or framework
5
Digital Health InterventionsThe tool does not meet digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configurationThe tool partially meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configurationThe tool fully meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration
6
Source Code AccessibilitySource code not publically available or not released under an open-source licenseSource 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 RevenueAt most two revenue streams exists. Revenue streams are largely dependent on time-bound project implementationsMultiple revenue streams/funders exist across project implementationsMultiple revenue streams and funding mechanisms exist, including at least one that provides for multi-year support of core software development, documentation and other key artifactsA 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 SupportDeveloper, Contributor and Implementor Community EngagementLess than 10% of estimated total number of developers, contributors, and implementers are on a communication platformUp to 20% of estimated total number of developers, contributors, or implementers, including some country representation, are engaged on a communication platformAt least 30% of estimated total number of developers, contributors, and implementers are engaged on a communication platform. Community leadership includes representation from countries where the tool is deployed
9
Community GovernanceThere is no community governance structure in place to direct continued development of the digital health toolSome informal processes for community management exist to direct continued development of the digital health toolFormal 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 RoadmapNo 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 DocumentationNo user documentation existsSome user documentation exists (training manual, demo videos) but only addresses a limited subset of common functionalityA 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 SupportLimited or no support in the software for multiple languages. Multi-lingual documentation / user resources are practically non-existentSoftware 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 languageSoftware 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 MaturityTechnical DocumentationNo substantial documentation of the software existsSome 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 without 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 ProductizationNo documentation available for deployment and configurationFull documentation available for deployment and configuration. A new implementation does not require the involvement of the core development teamSoftware 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 AccessibilityExtract 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 purposesA 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
SecurityNo security controls or implementation guidance are 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
ScalabilityThere are no jurisdicions (e.g. country, state) that manage 10% of their "entities" within the tool, and no performance and load statistics existThere 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 testingThere 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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100