3 Steps to Review our Collaboration Status: 

1. qMonth: Review what's already going on in the OpenMRS community roadmap here
2. qWeek: (~ Weekly) Review Collaboration Roadmap
3. qWeek: Review ohri tickets in Jira

Other Assets:

• UI Review: A side by side comparison of 3.x Demo vs OHRI Demo Sept 2021
• Shared Assets Doc: Explains Shared Assets vs Package-Specific Assets, and breaks down OHRI examples. 
• Architect Role Descriptions: OpenMRS recognizes the need for the roles spelled out in this document. Shared Assets require a pretty high-skilled developer, architect level person, to design them before a mid-level dev can work on them. Mid-to-junior devs need this kind of support in order to successfully work on shared assets. OpenMRS has some dev/5’s like this but not enough. The roles described in this document aim to address that gap. 
• Analytics Team needs: A detailed proposal for what team resources would be needed to thoughtfully address OpenMRS reporting challenges at scale. 
• OHRI Wiki Roadmap

Questions for This Week

• PM Check-ins
  • Updates/To-do check ins
    • Extension slot added? https://github.com/openmrs/openmrs-esm-patient-chart/pull/428
    • Need: OCL: Concept Support in Iniz (Support for Concept Name, Synonyms)
      • TODO: Grace f/u with team working on this 
        • https://github.com/mekomsolutions/openmrs-module-initializer/issues/140, https://talk.openmrs.org/t/how-concept-names-are-breaking-dbsync/34776/9?u=burke, https://github.com/mekomsolutions/openmrs-module-initializer/issues/141, https://github.com/mekomsolutions/openmrs-module-initializer/issues/136 
  • Cohort Module Next Steps
  • Next steps for Dispensing
    
    • Meet Tuesday? Mwariri to confirm design plan with Paul to get started next week.
  • Packaging reports
  • Concept Codes across distros (map concepts across different distros semantically)
  • FHIR Module ticket - endpoint for encounters 
• Sri & Fitti
  • OHRI Package things: OMRS not expecting to maintain (Shared Assets yes, OHRI package-specific widgets no.)
  • OHRI as library/package/toolkit vs as distribution → Suite of tools available to various sites
  • Move to lighterweight set; easier to merge / use things that will compliment implementers' distribution. Ability to pick and choose → microfrontends. Plan to split up - starting with form engine (Otherwise people have to take whole thing). May run into dependencies. 
  • "Programmatic side" - who is responsible for what? e.g. PATH for implementation - what does that mean for validating work thus far? 

#ohri Jira Tickets List