...
- 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
- Need: OCL: Concept Support in Iniz (Support for Concept Name, Synonyms)
- TODO: Grace f/u with team working on this
- Next steps for Dispensing
- Meet Tuesday? Mwariri to confirm design plan with Paul to get started next week.
- FHIR Module ticket - endpoint for encounters
- Programmatic work: Gap Analysis framework to share? Lead similar approach of __ EMR vs OHRI & 3.x Demo?
- (to further unpack w/ JJ & Brandon)
- Need: OCL: Concept Support in Iniz (Support for Concept Name, Synonyms)
- 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?
...