Global Goods Maturity Model self assessment
- Neha Verma
Intelehealth self-assessment | |||
|
| 13 | current overall score out of 30 |
Core Indicator | Sub-Indicator |
|
|
Global Utility (10 points) | Country Utilization | Low | Three or less countries or states actively use the tool as part of their health information system |
4 | Country Strategy | Low | Three or less countries or states have included the tool as part of their eHealth strategy or framework |
| Digital Health Interventions | Medium | The tool partially meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration |
| Source Code Accessibility | Medium | Source code exists on a publicly accessible repository and licensed under an Open Source Initiative approved license. |
| Funding and Revenue | High | 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 (10 points) | Developer, Contributor and Implementor Community Engagement | Low | Less than 10% of estimated total number of developers, contributors, and implementers are on a communication platform |
4 | Community Governance | Low | There is no community governance structure in place to direct continued development of the digital health tool |
| Software Roadmap | High | 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 | Medium | Some user documentation exists (training manual, demo videos) but only addresses a limited subset of common functionality |
| Multi-Lingual Support | Medium | 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 (10 points) | Technical Documentation | Medium | Some technical documentation exists of the source code, use cases, and functional requirements |
5 | Software Productization | High | 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 | Medium | 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 |
| Security | Medium | Role-based authorization exists, if appropriate. Guidance on encrypting all remote access (web interface, APIs) is available to implementors |
| Scalability | Low | There are no jurisdicions (e.g. country, state) that manage 10% of their "entities" within the tool, and no performance and load statistics exist |
Indicator definitions:
Core Indicator | Sub-indicator | Global Good Maturity Model for digital health software tools. Version 1.3 |
| ||
Low - 0 points | Medium - 1 point | High - 2 points | Notes | ||
Global Utility | Country Utilization | Three 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 intended | At 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 |
|
Country Strategy | Three or less 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 |
| |
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 partially meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration | The tool fully meets digital functional requirements (as defined by WHO's Classification of Digital Health Interventions) without signifigant customization or configuration |
| |
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 |
| |
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 | |
Community Support | Developer, Contributor and Implementor Community Engagement | Less than 10% of estimated total number of developers, contributors, and implementers are on a communication platform | Up to 20% of estimated total number of developers, contributors, or implementers, including some country representation, are engaged on a communication platform | At 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 |
|
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 |
| |
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 |
| |
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 |
| |
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. |
| |
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 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 |
|
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 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) |
| |
Security | No 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 |
| |
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 | |