RE: FGH OpenMRS codebase
Jan Flowers
Thanks for the enthusiasm – glad to have you involved Pascal! I do want a separate mailing for technical folks, not just development folks – so including system administrators, IT support teams, etc. We can start with our group here (including Starley, Alessandro, and Chris if they wish) and then add other technical folks as we get some of the core processes in place. I’ve created a mailing list: esaude-...@googlegroups.com Can I include Joao and Claudio in these conversations? Should I add Antonio Langa (spelling?) from the Ministry to this (Alberto – what do you think?) ?
Github -- Thanks for setting up the github. Let’s use eSaude organization with the project eSaude-EMR. If you could add yourself, Eurico, Alberto, Joao, Claudio, and myself as owners, that would be great. I assume for the starter website, you were thinking that would hold the technical documentation? I think that’s an okay starting point. For the implementation documentation, I’d like to stick with the main google site for now since the community is already using that.
Governance – I can definitely pull some of this out of the processes here at ITECH we did for KenyaEMR. I imagine the leadership team that you refer to will start with the project managers or SI directors in the partners orgs + us on this email. Once implementations start moving forward and development requests start up, this may evolve to a more specific team. However, until we have a draft process, I don’t want to move forward with including anyone outside of this email because they don’t understand this process yet and it will overwhelm them / distract them from planning for implementations. Sound ok?
Concept Dictionary – one I forgot to include, but glad you brought it up with the medical vocabularies. We are starting with the FGH concept dictionary, but this needs to quickly have policies set up for managing it as a central concept dictionary for use in the software. Chris is an excellent resource for this! There is a lot of talk around use of the MVP CIEL dictionary, and we do so in KenyaEMR with mixed results. I’m just pointing this out here to start the discussions.
Issue Tracking and Development Tracking –two different tools. One to track users issues / requests which ideally would be shared among the partners as a knowledge base for solving problems as well. Another tool to track technical issues for developers. They decided JIRA isn’t feasible for this group because of the cost. I’m not keen on the github tracking for a variety of reasons. We use Redmine for issues, Pivotal Tracker for dev here at I-TECH, but would be open to anything open source and easy to setup/maintain. FGH might be able to host a Helpdesk VM, or if M-OASIS/JEMBI was willing that would be great. I love that you guys are thinking about Helpdesk solutions btw – me too! I have a general guide that I shared at the workshop here – would love your thoughts, contributions/edits, etc: https://sites.google.com/site/openmrsmozambique/implementation-packet/system-support-structure-guide
Roadmap – how about if we just start with a google doc similar to this? https://docs.google.com/document/d/1yFlRErDTmmUslBUnfBDMC9jWM-SsQPQMGQfYfS29yLM/edit# Should we include Concept Dictionary updates as separate or within the software releases? Guess that depends on how we decide to manage it?
Computing power – right now FGH is the only one working on the code, and they’ve been ok so far. But yes, agree that as we move forward we may want to figure this out. I would consider this an issue to address a bit further out. Sound ok?
Community engagement – I’m purposely starting small to keep things very focused. I’ve seen a lot of these projects spiral quickly out of control and fail if they try to take on too much too quickly. But I agree we should keep these in mind as the group moves forward and things pick up.
Ok – lastly, I’m going to start some concept notes around all of those things outlined above where we can track decisions and plans to accomplish these things. Then we can focus on one piece at a time since our resources are limited. Let me know if anyone is opposed.
Eurico – I really would like to hear your input on this approach. Please let me know if you think we need to move in a different direction or if doing something differently would be easier for you.
Thanks so much for the input – please keep it coming!
Jan
From: Pascal Brandt [mailto:pas...@jembi.org]
Sent: Thursday, February 13, 2014 1:32 AM
To: Jan Flowers
Cc: Eurico José; Alberto Munenda; Shade, Starley (Starle...@ucsf.edu); Alessandro Campione; Chris Seebregts
Subject: Re: FGH OpenMRS codebase
Hi Jan,
I'm more than happy to get involved in this (or take the lead). In regard to your points:
· Public repository of the OpenMRS FGH code – my preference is to move it to an eSaude github account that can be managed by this small team
I've created an openmrs-mozambique GitHub organisation and starter website that we can use. I've also created a few others (esaude-emr, esaude, mozambique-esaude, esaude-mozambique) in case we prefer a different name. When we decide on a final name and core developer group I'll add all the necessary members (and code once I have it).
· Managing code changes (governance)
Sure, we'll certainly need some process documentation here. There will probably need to be a leadership team to decide on features to implemented. There will also need to be a group of core developers allowed to push code to the master branch. Hopefully we can grab a lot of this process from the OpenMRS core team and perhaps ITECH.
· Change management process for larger community (long-term governance)
The leadership team will need to take care of this too. What different kinds of change management are we referring to here? If we're including things like medical vocabularies, then I think Chris would be a great team member here.
· Issue tracking (helpdesk) and software development tracking
GitHub has a built-in, light-weight
issue tracking system that we can use for free. If we need something more heavy duty we could consider
Trello or
JIRA. At Jembi mOASIS we use JIRA for our software project management and planning, as does the OpenMRS core team. There is a possibility that we could use our JIRA instance to manage eSaude EMR, but there would be licensing costs involved in adding more
users to our instance.
Helpdesk-type functionality is something we've been thinking about a lot at Jembi mOASIS recently (although we're still in the early stages). We've had some experience with
Zendesk, but I've also heard good things about
Desk. We have also set up a toll free phone number in the past, but I'd have to check up on the status of that project.
· Roadmap management
No system I've seen have as good roadmap management as JIRA. I think the GitHub issue tracker has milestones, but I'm not sure about Trello. Furthermore, this is a task that a leadership team would need to be heavily involved in.
One thing you may have missed is a central knowledge base such as a wiki to use as an information repository. We've had great success with using Confluence in almost all of our projects up to now. Again, there is a possibility we could host the eSaude EMR confluence space depending on licensing costs. That said, there are numerous free and open source wiki alternatives and document repositories.
Another thing that we may need to think about from a technical perspective is compute power during the development process. For example, we may need test and/or continuous integration servers, staging/pre-production servers, etc. At Jembi mOASIS we generally use Amazon Web Services for tasks like this, but there are costs involved (although there are cheaper alternatives). We may be able to use some spare compute power that we have, but I'm not sure how sustainable this would be.
The last thing I would want to think about is methods for community engagement. I know we have the mailing list now, but is open for public sign up? We may also need to separate things into separate streams (for example, we may need a developers mailing list). The OpenMRS core community also has channels such as IRC, a forum and a Q&A page. I'm not sure we'll need to duplicate all of these though.
Regarding training, I don't think I'll be able to comment on this. I know our teams have a lot of experience with training a wide range of people in the health sector on all of our systems, but I don't know if we actually have any resources to allocate at this stage. I think Alessandro would be best positioned to comment on this.
Regards,
Pascal
On 13 February 2014 01:57, Jan Flowers <jfl...@uw.edu> wrote:
Hello All,
Outside of the main OpenMRS mailing list and the community focus on implementations, I’d like to get started talking about some of the more technical work that needs to get done for the FGH OpenMRS code to become the eSaude EMR community software. You three are our core technical folks, along with Joao and Claudio. Pascal, I wanted to make sure it was okay with you before I included them in this discussion though. Let me know.
The list of things that need to start moving forward for the community to share this software are:
· Public repository of the OpenMRS FGH code – my preference is to move it to an eSaude github account that can be managed by this small team
· Managing code changes (governance)
· Change management process for larger community (long-term governance)
· Issue tracking (helpdesk) and software development tracking
· Roadmap management
Anything else I’m missing here?
In addition, I’d like to start thinking through the system administration trainings that are going to be needed. Eurico, you had mentioned you already had some materials / documentation you were willing to share. Do you mind sending those to this group and we can start looking into how to support you and the group in this aspect?
Thanks all – looking forward to hearing your thoughts soon,
Jan
------------------------------------------------------------------------------------------------------------------------------------------------
Jan Flowers, Sr. Informatics Advisor
University of Washington, Department of Global Health
International Training and Education Center for Health (I-TECH)
p: 206.334.5263
skype: jan.flowers
uw mailbox: 359932
If you want to go fast, go alone. If you want to go far, go together. - African Proverb
------------------------------------------------------------------------------------------------------------------------------------------------
--
Pascal Brandt
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 84 827 9342 | Office: +27 21 701 0939 | Skype: psbrandt
E-mail: pas...@jembi.org
Pascal Brandt
Can I include Joao and Claudio in these conversations?
Github -- Thanks for setting up the github. Let’s use eSaude organization with the project eSaude-EMR. If you could add yourself, Eurico, Alberto, Joao, Claudio, and myself as owners, that would be great.
I assume for the starter website, you were thinking that would hold the technical documentation? I think that’s an okay starting point. For the implementation documentation, I’d like to stick with the main google site for now since the community is already using that.
Governance – I can definitely pull some of this out of the processes here at ITECH we did for KenyaEMR. I imagine the leadership team that you refer to will start with the project managers or SI directors in the partners orgs + us on this email. Once implementations start moving forward and development requests start up, this may evolve to a more specific team. However, until we have a draft process, I don’t want to move forward with including anyone outside of this email because they don’t understand this process yet and it will overwhelm them / distract them from planning for implementations. Sound ok?
Concept Dictionary – one I forgot to include, but glad you brought it up with the medical vocabularies. We are starting with the FGH concept dictionary, but this needs to quickly have policies set up for managing it as a central concept dictionary for use in the software. Chris is an excellent resource for this! There is a lot of talk around use of the MVP CIEL dictionary, and we do so in KenyaEMR with mixed results. I’m just pointing this out here to start the discussions.
Issue Tracking and Development Tracking –two different tools. One to track users issues / requests which ideally would be shared among the partners as a knowledge base for solving problems as well. Another tool to track technical issues for developers. They decided JIRA isn’t feasible for this group because of the cost. I’m not keen on the github tracking for a variety of reasons. We use Redmine for issues, Pivotal Tracker for dev here at I-TECH, but would be open to anything open source and easy to setup/maintain. FGH might be able to host a Helpdesk VM, or if M-OASIS/JEMBI was willing that would be great. I love that you guys are thinking about Helpdesk solutions btw – me too! I have a general guide that I shared at the workshop here – would love your thoughts, contributions/edits, etc: https://sites.google.com/site/openmrsmozambique/implementation-packet/system-support-structure-guide
Roadmap – how about if we just start with a google doc similar to this? https://docs.google.com/document/d/1yFlRErDTmmUslBUnfBDMC9jWM-SsQPQMGQfYfS29yLM/edit# Should we include Concept Dictionary updates as separate or within the software releases? Guess that depends on how we decide to manage it?
Computing power – right now FGH is the only one working on the code, and they’ve been ok so far. But yes, agree that as we move forward we may want to figure this out. I would consider this an issue to address a bit further out. Sound ok?
Community engagement – I’m purposely starting small to keep things very focused. I’ve seen a lot of these projects spiral quickly out of control and fail if they try to take on too much too quickly. But I agree we should keep these in mind as the group moves forward and things pick up.