OHRI Package: Collaboration Roadmap
3 Steps to Review our Collaboration Status:
qWeek: (~ Weekly) Review Collaboration Roadmap
qMonth: Review ohri tickets in Jira
qQuarter: Review what's already going on in the OpenMRS community roadmap here
Agenda for Next Technical Check In:
Packages update
Dispensing update
Lab orders update
CBS & LIS integrations → FYI on ongoing work
Assessment update (feature comparison/gap analysis and Modules review)
Algorithms and Flags: Can we review approaches for each
Confirm alignment on Clinical Views; JSON config idea
Update on Branding
Update on Generic Widget
Diagram
UgandaEMR: Cervical CA screening use case for 3.x; plan to do gap analysis. Plan re. migration path: 3.x first; ohri next
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.
To-Do's:
Collaboration RoadmapColor Legend: PIH Ampath UCSF OpenMRS Inc BE = Backend FE = Frontend | |||
Done/Resolved | Now What We're Working on Today | Next Next Priorities* | |
Programmatic | Concept Validation with Sites & CDC HQ program teams UCSF HIV HTS & C&T Prototype Validation with Sites & CDC HQ program teams UCSF COVID Prototype Validation with Sites & CDC HQ program teams UCSF COVID Prototype review: Clinical OMRS Community SMEs (TAP Call - Dec 15) UCSF | ||
Technical | UI Review: 3.x Demo vs OHRI Demo Comparison of existing 3.x Demo/Community Assets vs OHRI Demo OMRS Inc OHRI Demo Bug Clean Up UCSF | DB Flattening - get reporting working with new paradigm Meeting w/ PIH re PETL. Interested in SQL approach. UCSF PRIORITY COVID Prototype review: Packaging Technical Review (TAC Call - Dec 13) UCSF Service Delivery Queues Requirements: UCSF Dev: UCSF Core Dependencies: Cohort Module (BE), Patient List Functionality (FE) COVID Dashboard UCSF Core Dependencies: Cohort Module COVID Package widgets UCSF
Note: Applying OMRS Package schema depends on microfrontending architecture (lerna monorepos) | Prep to microfrontend UCSF-OHRI Repo to be created into a lerna monorepo Eudson lead review to i.d. any dependencies? R/v with Narupa, JJ, others? What core needs are missing that are needed in Community Code / Shared Assets? Blocker Embedding Pt Chart Features into Forms Blocker Unclear who will lead design (Problem: Current silo between Form-Entered vs Widget-Entered Allergies, Drug Orders, Conditions, Appointments, Immunizations) Leverage existing squad work Test Results Drug Orders Service Summary & Enrollment Vital Signs ...and more Database Flattening |
Updates/To-do check ins
Package: Next step for packaging OHRI packages: draft package content; draft package schema
Goals for Nirupa / plan for working together with Nirupa
Shared Asset Topics
Dispensing Module
Lab Orders
Homepage & program dashboard
Access Control/permissions
Automatic Patient Lists
PM Check-ins
Follow-up items
Need: OCL: Concept Support in Iniz (Support for Concept Name, Synonyms)
TODO: Grace f/u with team working on this
Cohort Module Next Steps
Discussion Topics
Packaging reports
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
"Programmatic side" - who is responsible for what? e.g. PATH for implementation - what does that mean for validating work thus far?