Description: Read-out of results from one-text process. Group discussion of what these mean in practice.

Leads: Dykki, Edward

To Join Remotely:

Join the call: https://www.uberconference.com/info3285

Optional dial-in number: 716-293-6106

PIN: 63498

Rapporteur/Notetaker: Sandy Hawley

Notes from Session:

Key Questions:

1) Customizable vs. Configurable (Extensibility)

2) Platform vs. Software

3) Sustainability

4) Technology principals AND community principals

Think about key themes:

actionable items that align with principals
split of community vs. software principals
what are the teams/capabilities within the community: knowledge sharing (internal comms) is a top priority, including documentation: how do we operationalize this?

What is missing/additional questions:

need to better define process for integrating significant changes to core
able to customize code for local implementation (this is a different concept than what is appropriate for last mile, i.e. bandwidth)
sentiment behind reusable - have to build solutions that cost more with the reuse feasibility (community ensuring implies behavior).
- This is challenging - making it available is different than ensuring its "easy for countries to adopt" - these are different principals.
- Having a group of people who have long term funding to focus on the core would help solve the issue- worth effort to have resources to ensure the community is represented
can we define different paths at the start of implementation - either offer the "soup to nuts" ($$$) or more custom solutions
who manages the decisions, should we try to define governance?
can we break down goals for next year- we commit to doing x,y,z - to measure what we do, what do each of these means to us?
lets be explicit about how we are making these principals actionable.

What is key to preserve?

1) CONFIGURABLE vs. customizable (product can be tweaked, but customizable is more of a platform) - OpenMRS vs. Bahnmi
- OpenMRS prioritizes community, platform, software; ends up being backbone of software "platform for medical records whatever they may be"
- Thoughtworks building on top of that (out of box), not as broad - install, configure, it is a product,an application - Bahnmi is opensource; not intended to be modular- makes it very easy for implementors, faster implementation
- Do we want broad base logistics services or the full stack? Initially it was the full picture, but now, with time - seeing divergence, it's leaning more to a platform
- Can we be both- should be both- most sell-able feature is configuration (this is how it works for you) adds most value
  - what is the gap between product and platform
  - evaluating where to focus on product feasibility
- Offering the "soup to nuts" is important
  - borrowing from PSE, supply chain suite products- consider: do we want this to go into other processes?
  - suite of tools that work together
- Customizable typically includes: configurable, brand, multiple modules- lots of things to capture/define
  - a central repository of add ons that don't break the core, and vice versa
  - what goes in the core what doesn't?
2) APPROPRIATE
3) REUSABLE
Some of these principals apply to community and some apply to technology - what are we trying to answer? Community vs. Software.Platform - should we split them up? Both are valuable, but different
- technology principals AND community principals
- principals of community follow under
Think about key themes
- actionable items that come from principals
- Split of community vs. software
Comments requested via email or one text end of day Wednesday.

OPPORTUNITIES ACTIVITY (see Dykki's notes in PPT)

LMIS is not everything (it can assist you, but can't fix broader supply chain issues, LMIS is a component) it's more about complete, accurate, timely data/information
Gates VAN project- people and policy part should be included
- people need incentive to use tools- if OpenLMIS implementation is to be successful; people are necessary component
The people part is important, but should the community focus on this? Can it be translated, can people with varying skills use it/benefit from it? Technology implications vs. people implications.
It is responsibility of community to design for easy usability regardless of end user
Easy to use tool that allows (empowers?) implementers and stakeholders alike
Reason we see value (reason community is here) is because we want to reduce the overall cost of getting to high quality LMIS, AND embed intelligence
- MRS data model example- start with field-tested model
We're the factory trying to help implementations develop faster, better, more cost efficient (long term) solutions -that is the responsibility of the community; support as much as we can - that countries choose this product and use it (faster, easier, cheaper, better)

AREAS FOR COLLABORATION- how do we have cross-org teams

Communications
- internal: knowledge sharing- documentation, training, information sharing, community support
- external: general brand, messaging, awareness, shared assets (collateral, web, PR,)
Product Roadmap
Community Roadmap
Sustainability thinking

CAPABILITIES / REQUIREMENTS

fundraising/revenue generation
logisticians
experience design
product management/owner
evangelists
should be a requirement to assess and communicate the value- actuarial
systems integration, knowledge about other systems
supply chain domain expertise
academic partnerships- there are challenges because we are coming from very different worlds - trying to contextualize for us
- PSE- its about $, for us, there is no revenue model for our world- when our people have better systems we cost MOH more
development talent, health informatics, what systems can we use that are feasible with local workforce?
advocacy with MOH - explaining value and making appropriate recommendations based on resources

Artifacts: