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:
- OHRI Packages Content Inventory
- 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
To-Do's:
- Grace & Eudson 1:1: Plan re MF-ing/code breakdown; how Nirupa can support
- 2022 Priorties:
- Schema: address features that extend the schema; whether these need to be part of the standard
- MF-ing/code breakdown
- DB Flattening approach
- Interoperability with DISI
- Form Engines: review of strengths (lower priority; even reconcile)
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 |
- Questions for This Week
- 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
- Need: OCL: Concept Support in Iniz (Support for Concept Name, Synonyms)
- Follow-up items
- 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?
- #ohri Jira Tickets List