mHero Global Good Maturity Model
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
$
%
123
 
 
 
 
 
 
 
 
 
ABCDEFGHIJKLMNOPQRSTUVWXYZAAAB
1
core indicatorsub-indicatorGlobal Good Maturity Model for digital health software tools.

Version 1.1
2
LowMediumHigh Notes
3
Global UtilityCountry UtilizationLess 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 intendedAt 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 StrategyLess than two 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 does partially meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configurationthe 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 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 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 SupportDeveloper, Contributor and Implementor Community EngagementLess than 10% of estimated total of developers, contributors and implementers are on a communication platformUp 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 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 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 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 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
ScalabilityThere 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 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
Loading...