Use your browser's print function to output concept-note content only, with each concept-note starting a new page. Print to Adobe PDF to produce a file. (Note: Chrome and IE9 do not support starting a new page for each concept-note.)
Thank you for sharing your concept note. Great to see these ideas shaping up. Can you please add more about your Consortium team and further detail on the project description? It is unclear what "support the mobilization fo courtires to engage..." would look like in terms of high level activites and objectives. We'd also appreciate you tagging key words, using the WHO Systems Categories.
Have you heard of the work GHSC-PSM is doing around creating a Supply Chain Information Sytem Maturity Model for health systems across all the GHSC countries? It might be useful to connect with folks at GHSC to see if this work could be aligned with what they are doing or relate to each other.
I'd suggest connecting with Swaroop Jayaprakash at GHSC-PSM.
Thanks for your submission and looking forward for the full proposal. Will the source code behind the GDHI be released as open-source?
Yes - the source code is open source. Our source code is in a GIT public repository under the GNU-GPL license, so anyone in the public domain should be able to pull the code to their local machine. Let me know if you have any other questions!
Thank you for your concept note and I look forward to seeing the full application. I recommend as you expand the application you detail further the two user groups (those for Pulse and for Iota) and detail how the training content will differ for each user. Please also address sustainability of the content as well as how you anticipate additional content to be curated past the life of the project. If you have not already, I also suggest you engage with Digital Campus to expand the proposal. They may be a great partner!
Ginocchio, thank you for your concept note. Can you say more how PHYLAXIA works with other open source systems records such as OpenMRS or OpenSRP? It is not clear from your description who owns the medical card and how the interface works with other HIS. It looks like from your description, this may be used in Senegal. What other countries have deployed PHYLAXIA?
Hi Tony,
Looks like an interesting proposal, think it would be good to chat and figure out how QEWD and OpenHIM could work together as you suggest. I think there could be some good gains to be had around leveraging the value add of both systems in an implementation! Lets chat this through when we get a minute.
thanks Carl, thats precisely what we had in mind
Do let me know when you can connect, I'll drop you an email,
Understand we need to get collab proposals done within the next week
thanks Tony
From the previous comments I cannot tell if the partners interested in collaboration have been able to connect with each other to prepare a joint proposal, but I look forward to seeing this happen.
The concept/proposal makes a reference to an OpenEHR persistence layer (EtherCIS?) which looks promising. Is there a particular use case of QEWDjs with this layer that would allow a fast-track integration with OpenHIM making for a concrete opportunity for collaboration and a real test?
Also (possibly for consideration in a future proposal round), are there other ways to use the OpenEHR clinical models to help enable exchange even if the actual health information systems do not use OpenEHR? E.g. are OpenEHR modeling tools mature enough to create mappings that can help implementers to support data exchange between systems with weaker modeling capabilities? If so could those tools become global goods too?
Hi Jakub,
Thanks for your submission. Great to see the emphasis on the use of HL7 standards!
I would encourage you to reach out to some of the other submissions around OpenMRS and openIMIS. Maybe there are ways to create to collaborate on a proposal and split in a way that makes sense regarding the respective strengths of the different partners?
Cheers,
Nils
Hi Roman,
Thanks for your submission - workforce development is such an important part of strengthening health systems!
It would be great to expand on the integration with OpenSRP, but also to explore other potential integrations, for example with workforce management systems (eg. iHRIS) or pushing indicators to national HMIS (DHIS2).
Cheers,
Nils
Thanks for your concept note and looking forward to your full proposal. Please expand on the badges program and how this will improve health worker training. You may address this in the user stories section. It would be great to showcase any mockups of the badge program in the appendix of the proposal if you have images already created. Please also detail now this ties in with your other gamification experience and user design to improve gamification features.
Thank you for your concept note and we are looking forward to reviewing the full proposal. Please expand on the Ukraine based partner and any other partners you have identified to join your implementation consortium. As you develop the full proposal, please include indicators for measures of success for each of the phases. It would be helpful for you to also expand on how some of the features such as interoperability with DHIS2, will improve user experiences. Finally, please address sustainability beyond the life cycle of this project, were you to be funded.
The team at IntraHealth International would like to work with you on this project to make sure that OpenIMIS also integrates with iHRIS, the flagship human resources for health software and established global good. For UHC and the supporting insurance systems to work properly, the MoH and other stakeholders will need ot know who interacted with the patient and their status within the national health system. This is not only if they are registered or licensed medical practitioner, but that they are permitted to perform the specified activity. For example, a dentist should not be assisting with births.
Great news. While this system doesn't seem to allow for direct connections, you can email me here.
Hi Marie Hélène,
Thanks for your submission. I would encourage you to reach out to some of the other submissions around OpenMRS and openIMIS. Maybe there are ways to create to collaborate on a proposal and split in a way that makes sense regarding the respective strengths of the different partners?
Cheers,
Nils
Thanks Nils - This is definitely something we are open to and have some ideas on this. If you have any specific organisations/projects in mind do not hesitate to facilitate the link up. Thanks, Marie-Hélène
Thank you for your submission and looking forward to see the full proposal!
Can you describe in more detail the community consultation process during months 1-3? Will it be virtual, in-person, leverage the training academies, etc? How will you decide who is consulted?
During the software development life-cycle, will the the community be engaged in feedback/testing or does that only happen in month 9?
Thank you for your concept note and we look forward to your full proposal. Please be sure to list the documentation outputs you see coming out of this project, in order to improve packaging for Connect 4 Life to be more readily used by other partners. To remain in scope for this funding, make this generalizable and use existing partnerships to test the usabiliyt of your tools. Please also detail the outputs for Phase IV and how these will help future implementations. Link your work to sustainability models for Connect 4 Life and include measures for success for the phases of your project. As you state you are looking for partners, I suggest you reach out to Grameen Foundation to partner and see what of their tools you can adapt for this instance of MOTECH.
In addition to that, open-sourcing of the current code (1B) should be a priority before making the existing connections/transfering to other software (1A). In Phase 1B, it is unclear if you are only making the source code available only to the existing partners, or would it be generally open-sourced. Phase 4 is likely out of scope for a Digital Square proposal.
Additionally, What are the other potential partners besided BeeHyv? The proposal discusses how the tool can be reconfigured for different use cases outside of HIV - is this something that needs to be done by a software developer? As the backbone is MOTECH, can you discuss the currently supported interoperability standards from MOTECH that have been implemented in CfL? Are there others? As MOTECH is now being supported by Dimagi, we would suggest discussing potential collaborations with them.
Thanks for your submission and we are looking forward to your developed full proposal. It would be great to include some health-oriented usecases where the specific features mentioned would add value within the health domain.
Thank you for your concept note and next steps to expand this to a full proposal. Can you address how the time and attendence module could interact with payroll and other audit services for health workers? Please also make the contribution of Jembi more explicit other than applying what you develop for OpenMRS. Will Jembi be involved in the development of the work for iHRIS? If you have any diagrams on how the iHRIS and OpenMRS interfaces may connect, those would be helpful to add to the appendix of the full proposal. Finally, please also address the technologies you intend to use to collect biometric data and how those will sync with iHRIS.
It would be good to discuss how the biometric signatures for providers would be made available in a a health worker registry, in particular around the use of HL7 FHIR standards (I believe that it can be added as a an additional identifier).
There are also ISO standards for biometric data (e.g. for generating the signature) that would be good to explain how this would be used (e.g. NIST/ISO 19794-2 ). Will you be targeting any particular hardware devices (e.g. simprints for fingerprints) or just doing an image capture?
Independent of the hardware, it could be interesting to leverage the simprints automatic fingerprint identification system https://github.com/Simprints/libAFIS/wiki . How will biometric workflows be documented and taken to the OpenHIE architecture group?
Thank you for your concept note and we are looking forward to the full proposal. I encourage you to specifically outline the documentation outputs in the full proposal, particularly as blockchain is of interest to the larger DH community. You also mention this is part of a larger project in which some funding is outside the request to Digital Square. Detail those linkages and address sustainability in your full proposal. Finally, it is unclear what datasets you may be working with to test and develop the MVP. Please explain what data you intend to work with and if you have any ongoing collaboration with eisting DHIS2 users/Ministries of Health, that you plan to leverage as part of this project.
DHIS2 has just started making use of Kafka - this may likely be a good place for monitoring transactional changes to DHIS2 Aggregate and DHIS2 Tracker. Also, there is a DHIS2 FHIR proposal https://proposals.digitalsquare.io/50 and there may be more utility to looking at building out a block-chain infrastructure based on transactions in a FHIR data store rather than limiting to DHIS2.
There may already be some existing projects in the FHIR world that are exploring this. Can you comment on the use of alternatives to 'proof-of-work' that will be considered (e.g. proof-of-stake) to ensure that we are not inadvertenly adding unnecessary energy demands. The proposal https://proposals.digitalsquare.io/75 is in a similar theme - we would recommend that the proposals be combined with different work packages to for the various activities.
Good concept note. Are participants constrained to use dhis2 or can any entity simply join the network and use it for exchanging health data? The latter is more inclusive (and the more health applications the better). If the latter, we would consider participating as a node and our health need is to exchange health insurance claims. Another ouroose is to store business logic (eg, females can have orostatectomies and males can't get pregnant, etc)...
Hi Harsh,
Which DHIS2 building blocks do you forsee to implement OpenIMIS?
How would you plan to distribute the OpenIMIS-on-DHIS2 system to existing DHIS2 instances?
If a DHIS2 instances with the OpenIMIS configuration have been used in production (contains live data) and customized (for example additional fields), how would you keep that system updated if a new OpenIMIS-on-DHIS2 version is released?
Cheers!
Hi Harsh,
It looks like openIMIS is currently heading towards a rearchitecture to a more modern tech stack instead of a rewrite using DHIS2. However, there are interesting usecases of leveraging the flexibility of DHIS2 for reporting and visualising key indicators - i.e. using DHIS2 as an analytics / reporting / visualisation platform
It would be interesting to hear your thoughts on that.
Cheers,
Nils
Hi Nils
Yes, using DHIS2 as a dashboarding and reporting platform is gaining in popularity due to flexibility of configuration and scope for making customized reports and dashboards. Although there is an extra step of getting all the data into the system since data is captured elsewhere and has to be imported into DHIS2.
We have done such integrations where the data gets synced with DHIS2 through backend service and the users extract/view the data on the dhis2 side. One such intergation was with the ODK platform, where the data from the ODK was fetched nightly into DHIS2 for analysis/reporting purposes.
There are several ways to do such integrations API, database level, excel imports and the method of choice depends on the nature of the applications , hardware resources and manpower available.
With OpenIMIS, the key indicators once identified can be configured into DHIS2 and the raw data can be imported on a daily bases or a agreed upon frequency of time, although this means that multiiple systems are operational at the same time and maintainance of both can be a challenge but a complex system like this should not shy away from such a approach as well since there are obvious benefits of using a proven tool in the same domain.
Thanks
harsh
Thank you for your concept note and we look forward to the full proposal. I appreciate the linkages to the LIS COP Notice B activities and OpenHIE. Please expand on your description of the OpenHIE engagement in your full proposal, noting how you will specifically engage with the subcommunities. As you expand the proposal, plesae detail very specific outputs, such as the documentation for the HL7 integration. I recommend you also tie this closely with surveillence use cases, leveraging where DHIS2 is already used for eIDSR. Setting up some test instances or working with a Ministry of Health to test this interoperability would be extremely interesting.
Also, it looks like you are considering a facade interface to support the FHIR interfaces. Have you also considered a local FHIR repository to stand along side Senaite?
This is the approach being taken by OpenLMIS and possibly by DHIS2. See https://proposals.digitalsquare.io/50 for info / potential collaboration on FHIR interoperability with DHIS2 and https://proposals.digitalsquare.io/71 for productization of OpenHIE components. The latter can be likely utilized for the local FHIR repository.
We would encourage the adoption of HL7 FHIR (over v2 or v3) as that is the emerging concensus for standards within the OpenHIE commnunity and they are very few v2 or v3 implementations in SSA.
Sounds like this could also generate documentation / best practices for OpenHIE components that have not yet adopted container technologies.
Will this work consider taking steps towards creating an official repository of containerized apps for the OpenHIE community?
Thank you for your concept note and we look forward to the full proposal. Please build in any reference to OHIE18 as appropriate as you finalize your proposal. Please also specify how you anticipate harnessing the OpenHIE community and wiki to support this activity including hosting any final ouputs.
Thanks for your proposal!
Since there are a number of technology choices (e.g. Docker, Kubernetes), we would suggest an assessment/community input activity to ensure concensus around the choices and a (brief) landscape of what openhie tools have been packaged using which tech.
As the proposal packaging would be reflective of different use cases/domains - how would these different packages relate to each other/how will dependencies be described?
What documentation or support will be provided for onboarding new tools/domains into the packaging system? How will you handle cases when there are more than one component that can play the same role in the architecture? For example in Debian packaging, there is a "Provides" feature. Are there any thoughts on how this packaging can be used to scale?
It seems like the Lorem Ipsum proposal should leverage this setup - perhaps combine the proposals and include Lorem Ipsum as a specific workpackage in this proposal. There are some potential opportunities for collaboration with the following poposals: https://proposals.digitalsquare.io/50, https://proposals.digitalsquare.io/85 and https://proposals.digitalsquare.io/70 as they may benefit from some productization.
We like this proposal and are trying to connect with this team as per our thread /discussion here re openHIM.
https://proposals.digitalsquare.io/54
Please let us know how we can help each other by collaborating on this.
Thanks
Tony
This proposal has the potential to enable multiple OpenHIE use cases. The proposed use case around HIV case-based surveillance is a high visibility / high impact activity in many settings given UNAIDS and WHO guidance on this topic, but itself depends on multiple other functions that are also still complex to configure. The proposed workplan implements the use case in the final two months, but more basic use cases can be identified along-the-way as well.
In a clinical (or health services delivery) workflow, robust capabilities for patient identification (e.g. probabilistic matching and biometric identifiers) would be an enabler. With an infrastructure/deployment perspective, technologies that allow integration of relatively simple facility based systems but with varying quality-of-service environments for connectivity and bandwidth may also be a critical enabler. Please also include system wide concepts such as security and privacy considerations into account in options to configure a deployable instant HIE.
Thank you for your proposal and looking forward to the full proposal! Here a couple of questions and comments:
Will the BSIS make use of the OpenLabConnect for its lab hard device interfacing? see https://wiki.digitalsquare.io/index.php/Digital_Square_Investments_in_Gl...
What is the gap between what is in OLC and what AfSBT requires? The proposal mentions the issue of transcription errors for results of blood tests - what data exchange standards are proposed to be used here? Is there a potential Device -> OpenLabConnect -> FHIR -> BSIS route here?
For the offline/multi-site functionality, what is the tech stack that is being proposed? It seems liekly that BSIS could leverage an existing stack (e.g. DHIS2 Tracker, ODK2, etc) that already handles the data sync issues. It is not clear if new data-sync technology is being proposed here or not.
I personally believe that as an industry, we do not put enough focus on data privacy and security issues, and I welcome this effort to review DHIS2 privacy concerns and develop standards for all digital health systems.
On behalf of my team at IntraHealth, we would like to be involved in these discussions and help develop guidelines that benefit all digital health solution providers. We certainly would find privacy guidelines helpful in our own solutions, like iHRIS and mHero, and in our collaborative works with others.
Thank you for your concept note and we look forward to reviewing the full proposal! You mention in your concept note that the outcomes will be to other patient centric systems in LMICs. As you expand to a full proposal, please elaborate on this and how your outputs wil be made accessible for users beyond DHIS2. Please also explain a bit more about how why you are using the rapid TPP process.
Thank you for submitting a concept note on data privacy and security – a critical area of work for our community! A few questions on your concept note:
- How will you promote adoption of the asset or assets once they are developed?
- Will your security and privacy assets address data privacy issues across platforms – e.g., beyond the DHIS2 platform?
- Can you expand more on how will you align your asset development with letter and spirit of global guidelines, such as ‘privacy by design’ as outlined in the GDPR?
- Will your workbook asset take a holistic approach to all of the data privacy areas you outline here, or will you prioritize?
- On the TPP Expert Panel, in line with the Principles for Digital Development, how do you plan to include stakeholder-users – partners who oversee or implement public health programs that use DHIS2 applications, but who do not design the platform applications themselves?
- How will your asset address data privacy and security at the various levels of data input, aggregation, and storage?
Please also expand on your approach to seeking further funding for additional assets identified during the TPP process, but not covered by this funding mechanism. Thank you for submitting this concept note, and I look forward to reviewing your full proposal.
Ashley Bennett, PATH
See comments on https://proposals.digitalsquare.io/65 about possibly combining the proposals into one with a set of different work packages. How will existing work on security and privacy be leveraged - https://wiki.ihe.net/index.php/Enabling_Document_Sharing_Using_IHE_Profiles or http://wiki.hl7.org/index.php?title=FHIR_Bulk_Data_Transfer_Privacy_and_... .
Can you discuss potential channels for dissemmination of the workbook (e.g. would it be raised to HDC? would it be part of the dhis2 tracker academies?) .
How will you coordinate with Oslo on this proposed work, in particular on their community of practice https://wiki.digitalsquare.io/index.php/Digital_Square_Investments_in_Gl... ?
First, I echo other comments that there is a lot of value in this activity even without the direct connection to the DHIS2 application. Also, likely the project team are already aware, but just pointing to this case study:
“Using DHIS 2 Software to Track Prevention of Mother-to-Child Transmission of HIV: Guidance. “ https://www.measureevaluation.org/resources/publications/ms-18-127
which identifies some topics/issues from a practical implementation that would be in scope for this proposal.
Thank you for this concept note and I am excited to see the full proposal! I appreciate the consortium approach. Please expand the type of documentation you intend to create in the proposal and how this will be shared. Please also detail the type of Forum you indeed to harness for user feedback. Too, since knowledge of ORBF may be low, you may want to consider different avenues to present the app once it is complete. Finally, I do recommend you reaching out to UiO or HISP for input into this proposal.
Thanks for your proposal! It would be good to compare ORBF to Clinical Quality Language (CQL) https://ecqi.healthit.gov/cql-clinical-quality-language. What would be the advantage of ORBF over CQL? What are the advantages of ORBF over the existing DHIS2 program rules?
I know that the original Buendia project used OpenMRS as a back-end. Will Buendia v2 do the same? What is the relationship between Buendia v2 and the original Buendia software?
(I wrote the above comment, asking about the relationship to OpenMRS and original Buendia.)
Thank you for your concept note and the expanded work you are doing to expand to a full proposal. As you continue to develop this, please add the full proposal to the site in additional to the PDF. It would be good to align this work with some of the other facility registry activities funded through Digital Square. Please descibe how this would leverage the GOFR and Healtsites activities (Notice A and B respectively). Regarding OpenHIE, can you explain in more detail how the OpenHIE Community will be leveraged? You can reference this in the expanded technologies section of the proposal. Please also address sustainability beyond the life of this project, if it were to be funded, in your expanded proposal.
Thank you for your submission, in your fully developed proposal it would be great to claify whether the standards that are used for communication with existing and currently developed health facility registry services would be appropriate to sync data to a mobile app, and if not, how data would be synced without adding too much complexity.
Can you discuss in more detail about the proposed software stack for the mobile application? Will you leverage an existing tool (e.g. ODK2 https://wiki.digitalsquare.io/index.php/Digital_Square_Investments_in_Gl... or ODK https://proposals.digitalsquare.io/62) that can handle online/offline data synchronization and is geared towards this type of use case?
What will be the data model used for data capture - you mention OpenHIE, so presumably this is mCSD/HL7 FHIR?
Thank you for your concept note and we are excited to see the full proposal! Please be sure to address sustainability of this work beyond the life of this project, were it to be funded. I also encourage you to explore in the proposal how BLIS and the outputs may leverage the LIS COP work funded by Digital Square through Notice B.
Hi Amanda.
Thank you for the advise. Yes, I agree we need to leverage on the LIS COP and ensure we are connected to the best practises that we also help in technical capacity buiding, localisations and standaidsation of the LIS tools and technologies. I will update accordingly.
Thank you for your concept note and we look forward to your full proposal.
I would recommend adding a few examples with real-world scenarios of where the tools could be applied. Also, regarding the Tableau connector I would recommend to highlight if there are possible synergies to the PowerBI DHIS2 connector funded under Notice B. Can a common base be developed which is able to connect to different analytics tools?
When you develop the full proposal it would be good to break the areas of requested support into different workpackages which highlights any dependencies between activities. How will the Tableau connector leverage the on-going work for a PowerBI connector? Is there any opportunity in these connectors to make use of standards (e.g. ADX for aggregate data).
For the utility suite, how will you engage with the community - in particular how will you be determining detailed requirements? How will you do user-feedback testing? What work has already been done to ensure that these are indeed priorities for the community?
Thank you for your concept note and we are looking forward to the full proposal. As you expand, please address how this work, builds on and leverages the Gap Project funded activities through Notice A as well as the OpenLMIS COP work funded through Notice B. Please also specifically describe how you will facilitate collaboration and coordination with other projects. Numerous concept notes in Notice C reference OpenLMIS - would be great to cite this work (pending funding) together in this proposal.
Thanks for your submission and we are looking forward to your developed full proposal. It would be great to expand on the described examples, potentially in a storyboard-like form, so that the interactions between users and the job-aid or feedback features would become cleare. From a technical point of view. it would be helpful to outline the reasoning behind enhancing DHIS2 core rather than offering connecting point for external applications - which might also need enhancements in core, albeight more simple ones.
Although DHIS2 as an HMIS is mentioned at the outset, it seems that DHIS2 Tracker is a focus for this proposal - can you please clarify?
During the conceptualization phase, it would be great to incorporate broader DHIS2 community feedback. Also, a number of other tools already make use of structured/triggered feedback and it would be good to have an early assessment of those, identify challenges and generally incorporate past learnings. Another interesting potential is to review the DHIS2 FHIR proposal https://proposals.digitalsquare.io/50 - can the proposed logic be built of the data that would be expressed in FHIR here? This would allow utility not only for DHIS2 Tracker but other systems as well.
Thank you for your concept note and we are looking forward to the full proposal. Please address core software support for eLMIS in your proposal, ensuring you link other funding resources to the work so sustainability of these activities are clear. Please also include indicators/measures of success in your proposal. It is great to see the collaboration with the OpenLMIS Community. Please detail this further in your proposal, as it will be informative to see more explicitly how you envision those linkages to be.
As the team builds out the full proposal, it would be great if the team could articulate the stratgey and goals around the community support for Facility Edition once it is open sourced. I understand it wouldn't be a part of this scope but it would be good to clarify the goal or direction the team plans to take. Thanks!
Thanks for your comments and suggestions. In revised version will address your suggestions and comments for -- software support, funding sources, sustainability, success factors, community collaboration and linkages. Thanks
From what we understand, the GS1 standard is not yet being deployed at the facility level in most countries, rather it is focused on national purchasing/stores - were the three countries cited planning on rolling out GS1 at the facility level?
Can you describe in more detail what the gap is between activites 1 and 2 - in particular what are there things that are in 2 that cannot be covered by 1? For example R&R can be convered under GS1?
How will you handle interoperability/integration testing with OpenLMIS v3? If any gaps in API/interoperbility w/ OpenLMIS v3 are uncovered, how will those be addressed?
Hi Nils, thanks for your comments and questions. We're proposing to build REST API based sync with OpenLMIS 3 as part of this proposal. OpenLMIS in V3 does have a GS1 compliant product model. It is also building an interface with FHIR compliant Facility Registry (FR). eLMIS Facility edition will sync with OpenLMIS V3 every month (or on demand) to bring in all meta data (all background/lookup tables) in to it's own database. This will ensure that eLMIS facility edtition will be using GS1 compliant product codes coming from OpenLMIS 3 as well as using facility codes that are consistance across all apps.
Testing of interoperability with openLMIS v3 will happen as part of testing of the new syncing mechanism. I'll update the proposal in final version to spell out this in more details.
Hi Anand,
Thanks for your submission. I would encourage you to reach out to some of the other submissions around OpenMRS and openIMIS. Maybe there are ways to create to collaborate on a proposal and split in a way that makes sense regarding the respective strengths of the different partners?
Cheers,
Nils
Hi Ozren,
Thank you for your submission. Faud detection is very relevant to to the national health insurance community. Wih openIMIS transitioning towards a more modular system based on open standards it would be interesting to explore options of supporting running FWA analysis on FHIR compliant data sources.
Cheers,
Nils
Thanks for your submission and looking forward to your full proposal.
It would be great to add some details about the long-term strategy for self-sustainability. Additionally, regarding some of the integrations mentioned, will any digital health / information exchange standards be used?
Hi Jean-Pierre,
Thank you for your submission! We're not aware of significant openIMIS work in DRC at the moment and mos of the work on OpenIMIS is currently happening in Tanzania or Nepal - has CERHIS been tested or even rolled out in those two countries?
Cheers
Nils
Thank you for your concept note and we look forward to the full proposal. I recommend you rename this proposal to specifically align with the coaltion support requested - this will help differentiate it from the previous Notice B submission. As you expand the proposal, please include indicators and measures for success as well as a very specific list of outputs. Please detail how you will engage new coalition members and where some of your strategy documentation will be housed. Please also detail out the strategies including the goal of the respective strategy that you would set if successful in this application for funding.
Can you discuss how the steward would be selected by Bahmi Coallition members? Is this intended to be a rotating role? Are there any opportunities for a coallition member to contribute some in-kind resources towards this?
Hi Nancy,
Thanks for your submission. Good documentation, communications and community building are such important aspects of creating a sustainable global good!
It would be interesting to hear about how you are planning to sustain those functions from a human resource point of view - i.e. who will perform community management, communication activities on a medium and long-term horizon.
Cheers,
Nils
Thanks for this comment, Nils. We'll address this in the full proposal.
Thank you for your concept note and we look forward to your full proposal. I recommend you expand on the software program features you propose to develop/enhance and tie these into user stories on how this will improve WelTel for clients. Please also indicate measures of success/indicators for each of the workstreams. As you budget, we recommend you budget per workstream and include these workstream budget figures in your budget narrative. Finally, I recommend you address sustainability of WelTel beyond the life of this project were it to be funded, particularly the East Africa Hub Office.
Thank you Amanda. As we are developing the proposal and going through the various elements we have a few key questions related to whether we are in scope and should proceed.
First, the Global Good Maturity model seems to reflect health system informatics and excludes digital health aimed at improving patient care. WelTel is a digital health service that is aimed primarily at patient care, so is countries would use it as part of their patient care, not 'as part of their health information system'. We believe that improved patient care should come first, and that 'informatics/monitoring' follows. Cleary some of the work we intend for this is to link the patient care data into health systems data (EMRs/DHIS2), but the WelTel software itself is designed (and proved) to improve patient care and outcomes. Please clarify if we are in scope on this.
Second: despite the PATH Digital Square definition: Use Open Standards, Open Data, Open Source, and Open Innovation
From: Digital principles: https://digitalprinciples.org/principle/use-open-standards-open-data-ope...
..What being “open” means for your initiative will depend on practical and technical constraints, security and privacy concerns, and the dynamics of the people and networks in your space. For example, to what extent your initiative uses open source software will depend on the needs identified for your context and an assessment of which of the available options best meets those needs, factoring in their total cost of ownership.
The Global Good Maturity model does not reflect this.
This primarily seems to examine the level of open source code access, rather than either global good or level of software maturity. WelTel did open source a prior version of code via Mozilla 2.0, but found that this was not necessarily conducive to effective quality maintenance, scalability, and sustainability. In the poor remote areas we work, 'communities of developers' do not exist, and to meet SDGs and help close the digital divide we need well packaged and supported software solutions that are well supported and with quality assurance that cannot be affordably acquired by open source code - nor can a sustainable business model. We are working through best 'good licensing practices', which may include some degree of open source (not likely WelTel SaaS code, but certainly other know-how and most data). The Global Good maturity model does not fit with what we know about scalability and sustainability, nor with Square's own (more flexible and appropriate) definition of "open" above. Please indicate if we are in scope on this.
Thank you!
Richard
The description of the consortium team and the description of a timeline refer to integration with EMR and DHIS2 (presumably Tracker) systems. However, in the list of activities, there is no reference to a task/activity that describes specific work to establish this integration. What does this integration look like? Do you envision a direct interoperability or the use of an HIE?
The project team also emphasizes the positioning of WelTel as a clinical intervention. This is of course appropriate. However, the objectives of many EMR implementation is also as clinical intervention even if conventional clinical documentation is often mandated/prioritized. In an intervention that combines both an EMR as the facility-based clinical information system and the “frontline digital health service” as implemented by WelTel, how will you facilitate proper impact evaluation of both components?
Thank you for your concept note and we look forward to seeing your full proposal. I recommend you include information on how the COP would be governed and including steps you will take to ensure proper govenance and sustainability after this project if it is awarded. Please also include metrics/indicators for success throughout implementation. I appreciate a lot of work has gone into getting to this point - great to further highlight some of the requirements already gathered or attached some of this documentation as an appendix to your proposal.
Child Helplines play a critical role in Child Protection. This can be brought out more clearly if we can demonstrate some statistics such as the number of reported abuse cases, number of calls received either per month or per year, number of closed cases, escalated cases. These metrics can be brought out in the proposal especially for the East Africa region for those countries that have been using the OpenCHS. Thank you for the efforts to streamline the system and to make it replicable across many more countries.
Comments
Be sure to update your tags
Be sure to update your tags before July 20! Tags are an eligibility requirement to move into the full proposal phase.
The team at IntraHealth
The team at IntraHealth International would enjoy working with you on this effort. OpenInfoMan can already export some DHIS2 data in FHIR, but we too would like to see DHIS2 have comprehensive FHIR-compliant data export functionality.
Thank you for your submission
Thank you for your submission. Looking forward to review the full proposal!
Could you describe in more detail the community engagement strategy as well as the decision making process that will be followed regarding the design decisions that are left to be made.
If you are leaning towards the local FHIR repository, we would also encourage you to collaborate with the "Instant OpenHIE" proposal https://proposals.digitalsquare.io/71 which can help with the productizaiton/packaging of the local repo. Even if not, we would encourage you to support this proposal around the DHIS2 FHIR/mCSD support, which is essentially a local FHIR repository attached to DHIS2.
Additionally, the OpenLMIS group has also decided on a local FHIR repostitory to handle their FHIR interoperability - their proposal is here https://proposals.digitalsquare.io/85