OpenMRS Strategic Objective Planning: Year 2016

Team: Jan, Darius, Maurya, Andy, Burke, Pascal

Talk Thread: https://talk.openmrs.org/t/objective-3-distributions-goals-and-tasks-planning/3605

Status of work: https://wiki.openmrs.org/display/RES/OpenMRS+Community+Strategic+Goals

Objective #3: Actively encourage and support the development of OpenMRS Distributions, deriving and disseminating best practices and technologies from them

---

Jan and Darius pulled this back in from the Annual Plan document on Jan 6, and added effort and resource estimates. Adding together everything we noted below, the requirements are:

People

Distributions Lead & 2+ Volunteer Team Members (7w + 3d)

Endorsement Project Lead & 2+ Volunteer Team Members (5w + 2d)

Crossover Support

Implementation team (4w ++) (research not-well-served use cases; design and requirements of new features we want to bring in from distros)

Partnerships Team (to connect with dev partners)

Community Mgt Team (advice and hosting of Ratings platform)

Service Provider (coordination on Ratings platform)

Engineering Team (to roadmap, build/harvest new features we find in distros)

Operations Team

Collaborations

Partner to build Ratings Platform (8w) (TW can probably do this; we might want to offer the project to Soldevelo)

Partner to extend Atlas (4w) (a couple TW devs working on this now)

GCI Student (page for Distro Highlight videos)

---

Objective 3.1: The OpenMRS Community will support a process to improve access to and usage of downstream OpenMRS distributions by community members and other organizations.

Objective 3.2: The OpenMRS Community will provide a distribution evaluation system for community members to judge quality and appropriateness for use in their context.

Objective 3.3: The OpenMRS Community will incorporate technologies and approaches from distributions into the Platform and Reference Application, and share lessons learned and best practices.

Objective 3.4: The OpenMRS Community will help Distributions produce good products by guiding them to engage with community processes, leverage community knowledge, and share lessons learned and best practices.

----

Below here is the initial document that was reformatted and modified/updated for the Annual Operational Plan (https://docs.google.com/document/d/10TO1iG-_W05pbIq36WV_UDVK6uNHirKKERfphAIVunw/edit )

Goals for Meeting Objective

1. The OpenMRS Community will support a process to improve access to and usage of downstream OpenMRS distributions by community members and other organizations.

1. Create a place on the website to list distributions

1. Measures:

1. # of distros listed
2. # of page views of “Distros” page compared to OpenMRS home and downloads page
3. Have a “Distributions” page accessible from top level openmrs.org (header, etc)
4. “Distributions” page includes relevant info

2. Create definitions and categorizations of distributions (how is AMPATH different from KenyaEMR from Bahmni, and which are distributions)

1. Measures:

1. Have posted to OpenMRS Talk, and Tweeted, defining “Distribution” and asking for more distros to identify themselves

3. Identify important use cases that are not served by existing distributions and encourage distributions to cover these use cases

1. Measures:

1. Have carried out a process to do this

2. The OpenMRS Community will provide a distribution evaluation system for community members to judge quality and appropriateness for use in their context.

1. Develop plan for OpenMRS to certify/endorse distributions

1. Measures:

1. Have defined objective criteria for OpenMRS to endorse a distro
2. # of endorsed distros

2. Create process for distributions to apply for evaluation
3. Create team to manage evaluation process and oversee evaluations
4. Provide a way for OpenMRS Community members to rate and comment on distributions

1. Measures:

1. Have implemented this feature on the distros website
2. Are the comments that people are posting accurate and useful?
3. Average ratings (over time), # of ratings, # of comments

5. Extend Atlas so people can see where distros are being used, linked to distros website/contact information

1. Measures:

1. have implemented this feature

3. The OpenMRS Community will incorporate technologies and approaches from distributions into the Platform and Reference Application, and share lessons learned and best practices.

1. Bi-annual review of known distributions to find interesting features and approaches

1. Measures:

1. Published method to identify best practices modules, implementers, locators, etc
2. Process Identified/in place for the review.

2. Add identified interesting features to the Platform and Reference Application roadmaps

1. Measures:

1. # of features pulled in from distros

4. The OpenMRS Community will help Distributions produce good products by guiding them to engage with community processes, leverage community knowledge, and share lessons learned and best practices.

1. Ensure distro owners and developers are aware of standard community resources and processes

1. Possible approach:

1. FAQ or wiki page addressing someone starting a new distro

2. Measure

1. Does it exist?
2. Last review and update

2. create specific engagement pathways for endorsed distributions

1. Possible approaches:

1. time on design calls, showcasing on developer calls
2. channel for Talk, space on JIRA (just like local communities and Bahmni)
3. way to reach out to the distro leads

1. Talk space for distro leads? Or email list?
2. newsletter?
3. periodically ask for platform roadmap ideas

4. Include representatives of endorsed distros on Advisory Committee

2. Measures

1. # of distro showcases across the different channels
2. # of distro leads that participated in # advisory board discussions
3. have a documented process for how to reach out to distributions on a regular basis to keep them engaged, updated, and involved
4. have a Talk group for Distro leads/representatives
5. have a documented process for onboarding new distros
6. have a documented process for distros to ask for community feedback on features

3. document/highlight best practices and lessons learned from distributions

1. Possible approaches

1. recording (screen) showcases of distros and making available to community; wiki page listing all showcases
2. Wiki page template for distributions to post about their product and sharing best practices/lessons learned

2. Measures

1. # of recorded showcases available for community
2. survey of usefulness of the recordings (did people watch them, were they useful available right next to the recording)

4. identify distributions that are not already involved / engaged in the community and invite to participate

Questions and Comments (pulled out from the above list)

• Think about how the website listing distros integrates with the Atlas. (use vs origin?)
• Gather current distribution information

• identify distribution reps and make visible through a web/wiki site

• Need to define process for identifying important use cases not served by existing distributions...End of year process for this? Survey of community to understand unmet needs?
• Idea: Number of Features contributed by the distro could be a criteria for judging whether it can be endorsed.
• Potential additional measure: Potential (and actual) implementations should understand the distributions that exist, and be able to judge their quality and appropriateness, so they can choose the right distro for their use case

Meeting Notes Table of Contents

10 Nov 2016 Jan & Darius (planned)

04 Nov 2016 Jan & Darius

14 Oct 2016 Jan & Darius meeting notes

7 Oct 2016 Jan & Darius meeting notes

20 Sept 2016 Jan & Darius meeting notes

16 Sept 2016 Jan & Darius meeting notes

9 Sept 2016 Jan & Darius meeting notes

20 July 2016 Leadership Team Update

11 Dec 2015 Summit Session Notes

19 Nov 2015 2pm UTC Planning Meeting

16 Nov 2015 3pm UTC Planning Meeting

09 Nov 2015 Planning Meeting

04 Nov 2015 Planning Meeting

Distro Definitions (Draft)

Maurya’s Examples of Distribution / Case Studies / Etc

10 Nov 2016 Jan & Darius (planned)

• Process for harvesting episodes of care
• Scrum of scrums and PM

Future Items

• Agenda for Uganda session
• How to incorporate “related technologies/compatible technologies” into OpenMRS

• Talk forum, infrastructure use, wiki page
• Listing on related tech section?/category?
• Endorsement - partnership - can we be on their stuff as a listed partner too?
• On the new webpage, have an “Ecosystem” page where we highlight some of these and link to more info on the wiki

• Questionnaire for self-evaluating distributions and for implementers to eval fit
• How to make it more clear that RefApp is a type of distribution RE: Terry’s email

• Eric’s comment about “as long as it’s there, why wouldn’t somebody just use that?”

04 Nov 2016 Jan & Darius

Distributions status - follow up from advisory council

• Held meeting on Wed 2 Nov, received input from Eric
• https://notes.openmrs.org/2016-11-02-Advisory-Council-Call

• Endorsement is too heavy, too burdensome
• What about having a questionnaire for folks that are adding their distribution to the page, for the “read more” page - do you have installation instructions? If yes, put URL here, etc

• List instructions for installation, running
• Are you disease-specific
• Do you take contributions

• Have “recommended followup questions” for people to evaluate distros (can you follow the install instructions, how many github commits in the last quarter, …)

DONE Define “what is actively supported”

• Be actively supported. At a minimum, one person available via some electronic format (email, skype, IRC, etc) and with the contact listed on the Distributions wiki page.
• be actively supported (i.e. someone will answer questions about your distribution via an electronic channel, and this is listed on your distro’s wiki page)

DONE Andela project concepts

14 Oct 2016 Jan & Darius meeting notes

DONE [Darius and Jan] Posted Talk post and sent text to Jeff for blog post and carousel

DONE [Darius] Finalized Distributions Wiki

DONE [Darius and Jan] Held Distributions call on Developers forum where distribution members reviewed their distribution within some pre set questions: https://notes.openmrs.org/2016-10-13-Developers-Forum 

DONE Discuss how to categorize and work with groups that are not distros (so we don’t lose the threads) => created google doc as placeholder http://bit.ly/2dpJPKu 

Next time:

SCHEDULED Review output of 13 Oct Dev Forum => will discuss this on 31 Oct Design Forum

Process for onboarding/engaging distros and regular outreach

Discuss session agenda for Uganda meeting

7 Oct 2016 Jan & Darius meeting notes

CANCELLED [Jan] Create wiki page for Phillipines and get Art to fill out content

DONE [Jan] Reach out to Nigeria about distribution

DONE [Darius] Add Uganda to wiki page

DONE [Jan] Contact Jeff Re: get ready to add “distributions program” to carousel - need image and text

DONE [Darius and Jan] Write blurb for blog post announcement that will point to Talk

DONE Update operational plan spreadsheet

DELAYED Post the announcement (Talk, and a Blog blurb) before Thursday leadership call

Next time:

Process for onboarding/engaging distros and regular outreach - what next?

Discuss session agenda for Uganda meeting

20 Sept 2016 Jan & Darius meeting notes

DONE [Darius] Add a criteria to distros page about must be based on a currently-supported OpenMRS version

DONE [Jan] Work on adding Philippines distros

DONE [Darius] Reach out to HISP India about DHIS Hospital as a distro

DONE [Darius/Jan] Share announcement, wiki page, and website blurb with LT for review

Delayed [Jan] Contact Jeff Re: get ready to add “distributions program” to carousel - need image and text

DONE [Darius/Jan] New blurb for website downloads page: https://docs.google.com/document/d/1S1R6aSqkCY-j748Ckjh62sxgmS0c4PD9iTTHrlFj70Q/edit

• Review at LT

16 Sept 2016 Jan & Darius meeting notes

Reviewed Sept 9 activities, worked on the Distributions Announcement: https://docs.google.com/document/d/1LmKXmF43FzmmZ1fN4qGCWCG8-ek87geYGVwTfsLdPlA/edit

9 Sept 2016 Jan & Darius meeting notes

Should we require a live deployment to list a distro? Decision: not for now.

Immediate To Dos:

• Still need to publicize this [the definitions] as an “official release/start” of the distributions program (no blockers, will do soon)

• DONE [Darius/Jan] Write in the announcement style,
• Run it by Terry and Joaquin, also post to Talk
• DONE [Darius] Add small OpenMRS logo to the table on the wiki page
• 1/2 DONE [Jan] Add a details page for eSaude distro
• [Jan/Pascal] make sure eSaude Moz Talk category is active 7

• DONE Propose a session in the Uganda Impl meeting about Distro Endorsement Criteria
• Review openmrs.org, see if small edits to mention Distros make sense.

• DONE [Jan] Add a small blurb at the top of the downloads page linking to Distros wiki page
• [Jan] (Propose to website leads) 1. Add a box on the home page about Explore OpenMRS Distributions, 2. Combine the Demo and Download boxes

• Get image for Jeff
• Get text for Jeff

• DONE [Darius] Schedule Oct 13 Dev Forum for “Bi-Annual Review of Interesting Distro features” + design forum afterwards
• [Jan/Darius] The 1-to-2 problem: Bring it up on LT call, how do we get dedicated time from one of the OpenMRS developers to support a collaboration across 2 groups

• DONE / AGAIN [Darius] Send an email to Burke saying we’ll propose this
• WAITING [Jan] Add it to the agenda for a call

For next working session

• Reach out to each distro currently listed, say we want to have regular comms/engagement, and ask what they think that might look like

• Slideset?

• Official definitions
• Wiki page
• More prominence on web page
• Plan to consider Endorsement Criteria (in the future)
• [maybe] Plan to harvest features more deliberately

• Questions:

• What do they want/need from OpenMRS? (organizational, technical, etc)

20 July 2016 Leadership Team Update

Perf Measures Update for Q1 & Q2

• What happened, what progress was made
•  What was missed
• What are we changing direction on or delaying addressing

Q3 & Q4 Revisit schedule and targets

• Top 3 priorities (or more if we want)
• Plan for addressing those

Issue &/or concerns that we would like help with

(from Op Plan)

Objective 3.1: The OpenMRS Community will support a process to improve access to and usage of downstream OpenMRS distributions by community members and other organizations

• Published definition of distribution (OpenMRS criteria) and community accepted categorizations [4/16]

• Based on the discussions from the Summit, Updated the Wiki with a definition and categorization   https://wiki.openmrs.org/display/docs/OpenMRS+Distributions 
• Still need to publicize this as an “official release” (no blockers, will do soon)

• 3 Distributions promoted in the OpenMRS community [1st in Q2, 2nd in Q3, 3rd in Q4]

• Created a table in the Wiki to showcase the current known distributions (Refapp, Bahmni, KenyaEMR, eSaude)

• Identified gaps in use cases [9/16]

• No progress
• Will not make major progress until implementation team has resources (person, funding) and can formally do needs analysis
• #3 priority for Q3 and Q4 (probably #1 priority for Implementation team)

Stretch Goals

• Partnership with a distribution to address at least 1 missing use case [12/16]

• Will depend on identifying gaps

Objective 3.2: The OpenMRS Community will provide a distribution evaluation system for community members to judge quality and appropriateness for use in their context.

Overall: Do only minor wiki and website work. Delay anything significant until next year or later. (until there are many General Purpose Distros, this is not valuable)

• Show distributions on the Atlas

• Done

• Team identified and managing process [4/16]

• Delayed - Not done (depends on resourcing)

• Published defined objective criteria for OpenMRS endorsement of a distribution [6/16]

• Minimum done - put a very minimal criteria together for inclusion on Wiki page... this can serve as a very loose simplified endorsement / acknowledgment, but we need to make a decision about where in the spectrum we want “endorsement” to fall (loose by following these few practices, or strict with lots of criteria and evaluation (or do we have levels +/- a maturity model)
• Plan to do sessions/interviews at Uganda Implementers meeting to get input, and release a first draft in Q4

• 1 endorsed distribution [9/16]

• Delay until Q4 or later

Stretch Goals

• 2 endorsed distributions [12/16]

• Likely delay pending endorsement criteria

Objective 3.3: The OpenMRS Community will incorporate technologies and approaches from distributions into the Platform and Reference Application, and share lessons learned and best practices.

• Published method to identify best practices in distributions, modules, implementers, etc [6/16]

• There has been some interesting things happening among the distribution owners on their own that we should consider - collaborating on shared code, sharing ideas around use cases, etc.  
• This led to some discussion about the difference between going from 1 to 2 distributions/implementations using something, and going from 1 to N distributions/implementations (such as including in the RefApp/Platform) and the efforts involved.
• We see value in focusing on getting innovations from one distro to be used/extended by one more distro, and considering this a success. Once the 1-to-2 problem has been solved by distributions, we can work on the 2-to-N problem of incorporating these features into the Refapp/Platform.

• 1 review performed to identify interesting work [12/16]
• 2 features from distributions added to product road maps [12/16]

• With the discussions between the current known distributions, we see potential in a couple of features to be added to the Platform and RefApp:

• Episodes of Care
• OpenMRS.js
• Form Entry for AngularJS

• Plan to deliberately look for more examples at the Uganda Implementers meeting
• #2 priority for Q3 and Q4

• [NEW GOAL]  1 feature collaborated on by 2 distributions [12/16]

Stretch Goals

• 2 features from distributions have functional and technical requirements specified [EOY]
• 4 features from distributions added to product road maps [EOY]
• 1 feature harvested from distribution and integrated into OpenMRS product/s [EOY]

• Should this be revised to 1 feature collaborated on by 2 distributions, rather than trying to take the leap to include it in the RefApp/Platform?

Objective 3.4: The OpenMRS Community will help Distributions produce good products by guiding them to engage with community processes, leverage community knowledge, and share lessons learned and best practices.

• Documented process for reaching out to distributions on a regular basis to keep them engaged, updated, and involved [4/16]

• Not Done
• Top priority Q3 and Q4

• Documented process for on-boarding new distributions into the community [4/16]

• Not done, but there haven’t been new distros needing this.
• Plan to document-by-doing this opportunistically with the next new distro

• 1 new distribution with team members engaged in the community [12/16]

• Bahmni is more engaged in the community - posting their upcoming features on Talk for discussion, but not ready to fully collaborate on coding. eSaude has led a couple of design calls around episodes of care, participates some, but no sustained engagement.  Ampath (not technically a distribution) has started trying to collaborate directly with other distributions, but not fully engaged through the broader community on their distribution.

• 1 distribution lead actively participating in Advisory Committee discussions [12/16]
• 2 recorded video distribution showcases [1st by 6/16, 2nd by EOY]
• 3 Talk channels for distributions [1st by 6/16, 2nd by 9/16, 3rd by EOY]

• Bahmni done: https://talk.openmrs.org/c/software/bahmni
• Talk channel for Local/Kenya - but not KenyaEMR
• There is a talk channel for Local/Mozambique, but not used.
• KenyaEMR, eSaude haven’t pushed for this. eSaude might be interested. (Whether we do more of these will depend on interest from distributions.)

Stretch Goals

• 2 new distribution with team members engaged in the community [EOY]

11 Dec 2015 Summit Session Notes

• distributions

• goal to control the entropy ( not avoid it)

• share descriptions

• general purpose.
• specific purpose use case
• single purpose distribution ( is this really an implementation and not a distribution_

• ​​derive and disseminate best practices even if the software isn't reused

• 'intent matters'
• bundling for distribution

• organization and community wants to look at this in a different way

• support software to make them more reusable
• help one offs  to make them more reusable

• influence roadmap and derive best practices for the community

• lessons learned from distributions

• distributions vs implementations

• can the community influence the road map for a specific geographical area since that implementation already know what is needed/ known constraints that are from the community/ area

• Proposed that the EMR use case is the important use case

• unlike linux

• Goals of the distro strategic evaluation

• certification and evaluation system to help implementers and users ( good, bad appopriate)

• certification versus implementation--do you need to be certified only after implementation?

• or can you be certified PRIOR to being implemented anywhere

• endorse and certify distributions- good behavior/ characteristics

• ​consider highlight instead of certification
• only endorse on what we evaluate/ time limited
• what to do with some communities ( is there a negative to endorsement where some distros may fall out of favor-- is that bad??)
• automated testing program and use of the logo that can be used

• market based approach
• standard baseline criteria for distro to get 'something from OpenMRS'

• 'use of openmrs'

• what does this mean
• certification can be technical and use certain aspects

• ​for instance if OBS table is empty, you aren't using it
• what is fundamental to defining the use of OpenMRS

• bi-annual review of known distributions
• add features to the platform and reference applications
• best practice library ( including measures)

19 Nov 2015 2pm UTC Planning Meeting

Attendees: Darius, Jan, Maurya

• Go through #4 and add comments, measures etc

Action Items:

• Jan to reformat this document to give it consistent structure (done in the ops plan)
• Review and wordsmith everything (after the restructuring)
• Resource discussion: define small ask and big ask (status quo is not an option)
• Darius to send doodle poll for Monday and Tuesday

16 Nov 2015 3pm UTC Planning Meeting

Attendees: Darius, Pascal, Jan, Maurya

Action Items:

• Go through #4 and add comments, measures etc
• Review #1-3 and wordsmith
• Darius to send doodle poll for Thursday

09 Nov 2015 Planning Meeting

Attendees: Pascal, Darius, Jan

• Reviewed the definitions of OpenMRS distributions: OpenMRS distribution, general purpose, special purpose, and single purpose; revised and commented on (see definitions)
• Reviewed the revised goals from last week, added a 4th goal to capture the intention in the objective to “support the development”
• Started reviewing tasks and merging where overlap occurred, adding new ones where needed

Action Items:

• Review tasks and revise, if possible, add measurables
• Review Maurya’s links and comment on use

04 Nov 2015 Planning Meeting

Attendees: Darius, Maurya, Jan

• Are distributions “use cases”?  docker use case examples; actually they might be the opposite of what docker intends - not that you know that well-known companies use docker, but that openmrs is well-known and you want to see how others are using it
• distributions are openmrs partners downstream
• marketplace for distributions
• process for endorsing/credentialing distribution
• we have underlined key terms in the objective of which the goals should be formed around
• do we need more resources? lets start with what we want to happen first
• Question for the bigger group: Bahmni would like to get “advice” from OpenMRS leads/experts to inform future development. (E.g. quarterly call or something). Do we want to support this sort of thing? Where does it fit? (Supporting development of distros? Disseminating best-practices to distros?)

Overall process:

• Review top-level goals and ensure we have the right ones (aren’t missing any) (e.g. the sticky exercise was bottom-up; let’s try top-down and then merge these)
• Lay out definitions of distributions
• Define our framework

• e.g. Goal -> Activity -> Measurable items
• any alternatives?
• numeric measures >> boolean ones (where possible)
• doesnt have to be one-to-one relationship (multiple activites can have one measurable, and vice versa)

• Do we need two versions, (1) a with-the-resource-we-have-now plan and a (2) assuming-we-get-the-resources-we-need plan => instead of this approach, let’s come up with the complete list of things we want, and afterwards see if there is a small subset that can be done with minimal resources.

Action items:

• [Jan] Merge the top-level goals
• [Darius] Starting point definition of distributions
• [Darius] Doodle poll about next week’s calls (probably Mon & Thurs)
• [Maurya] Look for analogs (lists of Linux distros?) and takeaways

Distro Definitions (Draft)

OpenMRS Distribution:

A particular configuration of the OpenMRS Platform, OpenMRS modules, and (optionally) other integrated applications, that can be installed and upgraded as a unit.

Following are the different kinds of distributions that are available through the community (depending on the type of use case the distro authors intend to address):

General-Purpose Distribution

An OpenMRS distribution that intends to serve the worldwide audience of clinics, hospitals, governments, NGOs, etc, who want a patient medical record for purposes of clinical care.

Implementers who come to OpenMRS looking for an EMR will be directed to look primarily at these general-purposes distributions.

Examples: OpenMRS Reference Application, Bahmni

Not today: OpenHMIS (because you can’t install it as a unit)

Not this: “OpenMRS Clinical Trial Distro” (because it’s not generally for clinical care)

Special-Purpose Distribution

An OpenMRS distribution that is intended for a specific clinical or geographical use case.

A special-purpose distribution will not be suitable for most implementations, but if it does suit the use case, it may be the best choice. We should help implementers review the available options.

In addition, other developers and implementers can learn from special-purpose distributions, so it helps OpenMRS to have these publicly visible and documented.

Examples: KenyaEMR, MDR-TB

Single-Purpose Distribution (need a better name)

A configuration of OpenMRS that is technically built like a Distribution, but is only intended for use by one specific consumer.

Typical implementers should not see these distributions in their first pass evaluation of OpenMRS. Though other developers and implementers may learn from such a distribution, they will never want to implement it directly.

Examples: Mirebalais, PIH-EMR

Not an example: AMPATH (because there is no bundle that someone else can install)

Maurya’s Examples of Distribution / Case Studies / Etc

• https://www.docker.com/customers - Demonstrates Case Study Inclusion
• https://www.docker.com/partners - Demonstrates being a Technological Partner as our distributions are contributing back
• http://phonegap.com/app/ - Apps/ Featured Apps/ Case Studies
• https://www.sencha.com/customers/ - Showcase with customer spotlights
• http://www.theappbuilder.com/process.html - Great collaborative Knowledge sharing process
• https://appery.io/ - Customer - Case Studies/Showcase/Testimonials Partners - Different types of partners
• http://www.linux.com/directory/Distributions - Demonstrates Rating and displays a way to go through the process to get included in the distributions list
• http://swagger.io/swagger-champions/ - Great way to show Service providers
• http://swagger.io/commercial-tools/ - Demonstrates the tools using Swagger
• https://www.javascripting.com/?sort=rating - Sorting and Categorizing distributions example - this might be an overkill for our current use but might be a good starting point to think about while scaling
• https://www.canvas.net/pages/offer-a-course - Demonstrates an application process
• http://www.intel.com/buy/us/en/reseller - Demonstrates a nice way to find a service provider
• https://www.qualcomm.com/products/snapdragon - Way to demonstrate how to choose what is right for the user
• https://facebook.github.io/react-native/showcase.html - Showcase the OpenMRS distros