Archive: TAC Notes 2019-2022
Meeting Notes
Goal of this meeting: Review technical/platform/product decisions; response to issues coming up from community and help set/endorse clear technical direction.
Zoom link: https://om.rs/zoomtac
2022-12
2022-12-12 - Jen presenting on Dev Stages & how TAC can help with review process, so we can give more recognition to members
2022-10
2022-10-24 - Cancelled
Attendees: Daniel, Burke, Mike
2022-10-17
Attendees: Grace, Burke, Mark G, Mike S, Daniel, Ian, Eudson
Recording:
- Formally confirm the backporting policy for Platform as described here. Example context: Fix for this is really affecting O3 code; but if it's not backported, then the same code that runs against 2.5 won't work against 2.4. Support = continuing to care for the code.
- Agreement in principle. Something like “The OpenMRS Community strives to support the last 3 releases. Support for older releases is handled on an ad-hoc basis.”
- But: Does not mean every change is being backported. eg. someone making a commit for 2.5 because their org needs it, shouldn't be forced to also backport to other last 2 versions.
- Criteria for "Need to Backport":
- Priority Security Fixes & Major Bugs
- "Consider to Backport - but not required"
- If people you flagged who may be affected express clear reasons for needing a backport to up to 3 versions back
- Case-by-Case Discussion: An API endpoint or behavior update that could have an impact (API changes should be backported only when necessary because they're breaking changes; but also, improvements to API are reasonable to simply add to the latest/current release)
- When you want people running older versions to be able to use your code
- Not about the anonymous downloader - because we need to be realistic.
- 5-Whys Retrospective on how this drug-order bug was missed until now, and how we can improve accordingly.
- Why was this not caught for 2 yrs?
- Not used in production, not iterated on until recently
- Bug wasn't visible because ordering was broken/blocked in demo until recently
- Not enough quality demo metadata (drug metadata not possible to connect well until recently)
- Why does this seem "ready" when it's not? (i.e. it's a 0.0.1 release but seems like a 1.x, ready to consume)
- Bundled into monorepo with more ready stuff
- Why were the requirements not clear?
- Not clearly documented
- Ownership role over feature was not maintained
- Meds should be treated as a special, don't-mess-up case.
- Why not given more attention over time, no one "owning" the quality of it?
- No clear, regularly done O3 release process.
- Why did `${strengthQuantity * doseNumber} ${strengthUnits}` seem like a reasonable formula?
- Quantity vs Dose vs Strength are confusing to people.
- strengthValue and doseValue would probably be more clear as objects.
- Quantity vs Dose vs Strength are confusing to people.
- Why was this not caught for 2 yrs?
- Agree on vision and next steps for the O3 Release process and “Quality Gates” (see diagram & discussion here).
2 key takeaways:
- @next makes sense as the esm-version-source for dev3, but @latest makes most sense for o3, not test3, because marking an esm with @latest implies to the whole world on npm that the app is stable / ready for the real world. And this is not necessarily true for all stuff in test3.
- I’d like devs to indicate “I have tested X feature in dev3 and it works as expected” somehow - maybe through a label of some kind? Then test3 could pull in those specific updates; things that are basically halfway between @next and @latest.
2022-09
2022-09-19
- Reviewing core apps, UI commons, and appointment scheduling build issues
- Multifactor authentication support
- Dispensing updates
2022-09-12
- Deployment process
- Dockerizing deployment
- Dockerizing QA builds would be a big help
- Unable to publish to SourceForge
- Build issues – Bamboo agent issues
- yu issues
- Having some issues with terraform process
- Builds running out of disk space
- Ian disabled a misbehaving job (2.x RefApp E2E tests not cleaning up after themselves)
- yu issues
- Issues with Dispensing
- See Questions about Pharmacy designs
- Dispensing Design Components
- Probably want to avoid tackling multiple tabs in MVP and focus on one or two filters: (1) prescriptions that need to be processed (e.g., today's prescriptions) and (2) completed.
- Avoid showing all prescriptions by default (list will be WAY too long)
- Other filters (e.g., RETURN) still need to be defined
- Status is more about dispensing status than order status.
- JIRA Graveyard quarterly cleanup
- Will be transitioning issues according to OpenMRS Jira Clean Up Protocol (aka "Quarterly Graveyarding")
2022-08
2022-08-08
- Possible topic: Provider Messaging
2022-08-01
- DevOps skills – do we need dedicated effort?
- Overlaps with CI/CD, tooling for QA, etc.
- It might help to recognize this as a separate discipline
- Similar to QA, in having leadership to help wake up thinking about the discipline for the community, bringing the expertise and helping lead the big tasks, and raise devops awareness & skills amongst community devs
- Announcement
- Virtual Design Conference & Workshop for 31 August - 2 Sept
- What would you like to learn, show, & tell during the conference?
2022-07
2022-07-25
- Computed observations
- UCSF is using stored procedures to compute observations
- Storing all computed observations in a "computed" encounter
- Issues
- When is a computed observation recomputed?
- TTL
- Dependent values change
- Tracking dependencies across observations
- Definition should include all dependencies
- Would like to get away from building our own BRMS (business rule management system)
- When is a computed observation recomputed?
- UCSF is using stored procedures to compute observations
2022-07-18
- Discussion Board (real-time messaging) feature (Slide deck)
- Requirements
- Search and add users to a discussion
- See who is online
- Send notifications to participants
- Ability to remove participants
- Ability to add files/attachments
- Challenge
- Using web sockets via Spring WebSocket API and STOMP messaging protocol, but running into issues
- Requirements
2022-06
2022-06-06
- Leveraging drug formulary for drug orders widget
- "As far as the opportunity to make urgent progress with UCSF and drug ordering for OpenMRS 3.x, any work to pull drug formulation information from the drug table (instead of frontend JSON config files) would be a step in the right direction." -talk
- Adding "category" to forms (tags?)
- Use case is to be able to limit a list of forms (or default) based on categorization (label/tag) of forms.
- Why use tags instead of configuring an explicit list of forms (e.g., within configuration)?
- A single UI element needing a specific list would favor configuration; whereas, if there are multiple UI elements or areas of the application that want the same grouping of forms, tagging might be more appropriate.
- If there are context-specific needs, then a backend (tagging) solution might be preferable.
- Would it be more appropriate to associate forms with programs? Are tags actually a workaround for the lack of relationships between forms and other resources (e.g., programs)?
- A program may still have 50+ forms and being able to group forms in smaller groups would be useful (which would favor tagging)
- Distinction between categories & tags?
- Categories would be a pre-defined set of "buckets" and forms could be placed in one or more buckets
- Tags would be a "folksonomy" where removing the last use of a tag would remove the tag
- Next steps?
- Ian Bacher will make some tickets for this
- Feedback of deployment (experience from Grace Potma's recent travel
- "I wish we could have just grabbed OpenMRS as a Docker image."
- "Is it possible to deploy KenyaEMR and whatever system together so they could deployed at once" ... "Yes, we're exploring Docker for this."
- "Your 3C approach makes sense, but could you add 'D' for deployment? It would help if Docker was included to make deployment easier."
- Existing materials
- Ability to jump from form into patient chart
- Use case: when using a form with a lot of data, we'd like to be able to show the data in the patient's chart and then take you to that relevant part of the patient's chart while completing a form. For example, while form is being edited in the right panel, being able to click on something to navigate the patient's chart (left side of the screen) to specific data within the patient's chart (i.e., navigate the patient's chart without having to leave the form). In a tablet view, this might mean providing a way to get back to the form.
- Design for notifications/alerts and how will they be supported
- Not enough time to discuss today, but we should think about how we will support Ciarán's designed for notifications on the backend
2022-05
2022-05-23
- How to handle needs for data migration - OpenMRS Talk
- For Ethiopia, they have data in FHIR format for >100 resources and only ~30 are currently supported by the OpenMRS FHIR module
- Current goal is to migrate to OpenMRS database
- While OpenMRS is strategically aiming to migrate toward full FHIR support, adding new resources (e.g., MedicationDispense) is non-trivial and includes the need for new Platform releases.
- What is driving the data migration? Reporting vs. clinical use?
- Primary driver is to have MVP containing existing data and for clinical use.
- Could focus on how could each resource be represented in OpenMRS and focus on how to migrate existing data into OpenMRS model
- Enumerate each piece of data and how it would be represented in OpenMRS
- Manually migrate those that have a clear equivalent in OpenMRS
- Focus on alternatives for those that are not currently handled by OpenMRS (e.g., Care Plan)
- Example of PIH migration code
Emergency Department stuff (a little bit)- Sync-something becomes a core part of platform
- Grace Potma will be posting to Talk soon about this
2022-04
2022-04-25
- Inpatient vs outpatient care
- Care Settings will need design
- Ideally would allow for bed management to be coordinated with external systems (e.g., ERP)
- Look at Bahmni for successes in inpatient setting and learn from workflows
- Could start with simple bed management
- Bed management module provides backend support for bed management metadata/configuration
- Bahmni contains features that leverage bed management to provide inpatient features
- Are there near-term implementation needs for inpatient?
- Steven Wanyee shared that IntelliSoft has three cases that could use inpatient support (e.g., work in Botswana is beginning as outpatient, but will have inpatient needs soon)
- Mekom has some work in late 2022 or in 2023 that could use inpatient features
- Care Settings will need design
- MAR - Medication Administration Record
- There's some demand for this feature
- Update on Reporting & Analytics
- Mike & Burke have been using Analytics Engine Squad calls to work through a way forward
- We've divided the problem into four areas: (1) Change Data Capture (CDC), (2) ETL, (3) Data storage, and (4) Reporting & Analytics tools. Each of these areas has a variety of options in tooling.
- We'd like to see if we can align community efforts/energy around a shared approach to CDC.
- Mike & Burke have been using Analytics Engine Squad calls to work through a way forward
- Reference ranges
- OpenMRS historically has defined reference ranges within a concept; however, ranges vary by context, patient demographics, etc.
- LIVD (within the SHIELD project) on lab interoperability is debating where knowledge of references ranges should be – with the concept vs. with the result.
- Would want to align with these kinds of efforts
2022-04-18
2022-04-11
- Medication Dispensing
- We discussed and tried to provide answers/decisions for Mike Seaton and his work on dispensing
- SDK support for OpenMRS 3
- Ian Bacher and Daniel Kayiwa will update the GSoC 2023: Improving the OpenMRS Developer Experience: Updating the SDK page (and rename to something like "Improving the OpenMRS Developer experience through improvements to the SDK"
- Handling units within the FHIR (fhir2) module
- Backend support for draft forms/encounters
2022-04-04
- Backend support for draft forms/encounters
- How/where should draft forms be persisted?
- In a draft table, linked to patient/encounter
- Should we allow draft of anything?
- Probably better to handle separately as a approach for persisting application state
- How long are drafts persisted?
- Forever?
- If we can distinguish between draft and voided draft, then business rules can drive it.
- Need to include last updated time.
- Who can access drafts? Can they be shared?
- Permissions can be applied on top of draft feature as long as we know who created the draft.
- Making forms uneditable is a separate issue.
- Would use permissions to control this
- Design ideas
- Form content
- Link to encounter? We wouldn't have encounter in common use case (not created until form validated/submitted/saved).
- User
- Date updated
- Patient
- How/where should draft forms be persisted?
2022-03
2022-03-28
- Modeling for Drug Orders in 3.x (Formulary vs Prescription vs ?)
- Example
- Concept: amoxicillin
- Drug: amoxicillin 500 mg tablet
- Order template: amoxicillin (500 mg or 1000 mg) (orally or per gastric tube) (two or three times daily)
- Order set: (1) amoxicillin 500 mg orally three times daily, (2) amoxicillin 1000 mg orally three times daily
- Formulary informing vs enforcing orders
- Formulation chosen by ordering provider or by pharmacist
- Example
- Draft encounters (saving them in the backend)
- Would love to have these. Needs design work.
- Any synergies with ICRC project?
- Patient search? Quick forms?
- Viewing tables of data?
2022-03-21
- Continue walking through steps involved in adding OHRI package to OpenMRS 3.0
- OHRI Package on 3.x RefApp
- Idea: Your EMR on 3.x (Docker-Compose-Up for 3.x)
- Handling concepts from multiple packages
- Happy path would be union of concepts, using UUID for equivalency
- Continue discussion on Community Forms Schema
- Notes from 2022-03-17 discussion here
2022-03-14
- Dispensing modelling (Medication Dispense wiki page)
- Core vs module? Core (or core module)
- Medication Dispense Data Model
- Medication Dispense Java API
- Continue walking through steps involved in adding OHRI package to OpenMRS 3.0
- OHRI Package on 3.x RefApp
- Idea: Your EMR on 3.x (Docker-Compose-Up for 3.x)
- Handling concepts from multiple packages
- Happy path would be union of concepts, using UUID for equivalency
2022-02
2022-02-21
- Cancelled for OpenMRS Holiday
2022-02-14
Attendees: Burke (OMRS), Mike (PIH), Mark (PIH), Namanya, Daniel (OMRS), Grace (OMRS), Romain (Mekom), Tendo (Vol), Zak (Mekom), Ian (Brown)
Mentally walking through adding a “package” with an ESM, module, and concept to OMRS 3. What are the steps we expect to happen?
- We walked through build process
- Would like to improve build process of frontend so we don't have to re-download assets each time we assemble the frontend and so we can deploy frontend in different locations without having to re-assemble the frontend (preferably without having to search & replace variables within index.html)
2022-02-07 - recording
- Continuing the discussion on OpenMRS Packaging conventions (Draft Schema for Packaging)
- "A package is a definition of what artifacts are that make it up" -Mike Seaton
- What string format convention do we use when referring to an asset (ESM, omod, metadata, etc.)?
- Can take existing conventions and document them (e.g., what we're doing in distro.properties)
- Which versioning format do we use? Are there libraries for this?
- Prefer to adopt a well-established convention instead of our own custom syntax
- Look for library to convert between npm <=> maven
- For modules, do we organize by asset type (omod, esm) or build tool (maven, npm)?
- Defer
- Mentally walking through a simple build process. What are the steps we expect to happen?
- Ability to refer to config or metadata by URL in properties file
- Do frontend modules declare what backend modules they depend upon? If not, we'll want a convention for this. Can we add these data to packages.json?
- Mike would like to have distro.properties that refers only to versioned artifacts (e.g., in maven). So, we would list all ESMs; rather, we would refer to a pre-built frontend artifact that contains the built artifact.
- This may be a fundamental difference between distro & package definitions: distro refers to built artifacts, while a package definition will need to refer to ESM source.
- PIH uses a pom.xml like this to generate a frontend artifact (turning a definition like this into a maven artifact like this), so changes to non-frontend parts of the distro (e.g., bumping an omod version) doesn't require re-building the frontend.
2022-01
2022-01-31
Attendees: Burke (OMRS), Allan (Ampath), Amos (UCSF), Daniel (OMRS), Emmanuel (Mekom), Eudson (UCSF), Grace (OMRS), Ian (Brown), JJ (Ampath), Juliet, Lars (UCSF), Mark (PIH), Michael (PIH), Jonathan Odora, Romain (Mekom), Stephen (UCSF), Tendo
Agenda: Reporting Strategy
We would like approach(es) that leverage existing tools to provide a standalone solution for reporting/analytics that can be scaled, when needed, to separate server(s) or into the cloud:
We want to focus on the four areas of (1) change data capture, (2) transform, (3) data store, and (4) reporting/analytics and want to keep in mind that a primary consumer of analytics will be the EMR itself:
- CDC (Change Data Capture) solution
- Debezium
- Debezium is lightweight, but requires Java for integration into pipeline, listening to log files and manually marking changes.
- Haven't tested with large dataset.
- Kafka/Connect behind Debezium
- Kafka with Zookeeper & Kafka/Connect doesn't require programming, but needs lots of RAM (8GB+)
- Newer Kafka (3.0.0) may not need Zookeeper
- Debezium and Camel
- Still need to write some code to listen to changes, but not as much
- Debezium
- Data processing
- SQL
- FHIR data store
- Spark
- Can use SQL or Python. Also supports R, Java, and Scala. SQL is probably most widely known in our community.
- Flink
- Can use SQL. Relatively simple to use.
- Has its own optimizer engine for queries.
- Flink/CDC is a wrapper around debezium, but may not configure debezium optimally.
- Requires Zookeeper (but this might change in the future). We'd need to figure out how to configure to avoid needing lots of RAM.
- Can run as application mode (as a single jar without clustering)
- Data store
- Cassandra
- Dependent on proper partitioning.
- Frequent writes (e.g., CDC) might slow down reads.
- Parquet
- Much more efficient than CSVs
- Postgres
- Simple flattened tables
- For example, Mekom using 4 key flattened tables: Concepts, Visits, Patients, Obs
- Simple flattened tables
- Delta Lake with Parquet
- Requires SSD for real-time processing of streamed data. Can lag 5+ minutes with peak loads.
- Supports both batch and streaming workloads.
- Druid
- Cassandra
- Reporting/analytics
- BI tools (e.g., Power BI, Jasper Reports, Tableau)
- Apache Superset
- Nice metrics & calculations
- Supports SSO
- Kibana
- Requires ElasticSearch (i.e., ELK stack)
- Nice visualizations
- Limited with heavy calculations
- Need to have option for OpenMRS to read from reporting
Some groups using standalone OpenMRS needing some capability for simple flattening. Other groups looking for enterprise approach to analytics.
Strategy to go forward
- Experiment and stay in touch (e.g., Slack)
- Expand Analytics Engine Squad calls to move these forward
- Center discussion around these four areas: CDC, ETL, Data store, and Reporting/Analytics
2022-01-24 - recording
2022-01-10
(Ian) Priority and Status are both concepts. View works well if you're in a particular clinic. Problem right now is which clinic you're in - this is what drives the "Waiting for" specifics. Might also want a view of all patients waiting for my particular service (i.e. dynamic pt list) - question of "what data is driving the particular view that this particular user is seeing" - e.g. all pts anywhere, or ... e.g. someone at triage desk might primarily want to see triage pts.
(JJ) Goal is to see the status of all patients. MVP is that movement is manual (user adjusts where pt goes next).
(Ian) Need agreement on general context for these queues: Encounter? Visit? ...?
Decision: Need check-in with Burke around what's required - terminology and what fields we'll capture. Not massive conceptual change. Requested at: https://talk.openmrs.org/t/backend-support-for-service-delivery-queues-workflows/35247/52
2022-01-03
- Notice F for Digital Square projects (technical proposals due 12 Jan)
- ANC package
- OCL integration
- QA
- GSoC 2022 planning
- Coming up with changes for GSoC (not just students)
- Packaging
- Reporting
- Leveraging
- Apache Flink vs Spark for streaming
- Apache Superset for visualization
- Leveraging
2021-12
2021-12-20
- Backend Support for Service Delivery Queues / Workflows
- Ian Bacher was pulling together ideas
- Packaging
- Discussion happening in Google doc comments
- TODO: Burke needs to pull into Talk thread
- Planning for Reporting foundation
- Botswana project
- Botswana has been using OpenMRS for TB program
- Now considering OpenMRS at national scale.
- OpenMRS 2.x vs. 3.x. Have started with 2.x.
2021-12-13
- Log4Shell vulnerability
- Upgrade Platform or apply mitigation to avoid anonymous attack vulnerability
- Plan to tweet
- Backend Support for Service Delivery Queues / Workflows
- Do we support multiple states per Visit? Per Encounter?
- Can we support queueing outside of Visits/Encounters?
- Packaging for UCSF COVID package
- Packaging draft
- TODO: Burke to find Talk post on packaging and bring it to Eudson's attention
- Planning for Reporting foundation
- OpenMRS 3 (and OHRI) need an out of the box, scalable reporting solution beyond reporting framework
- AMPATH & Google have
- Can analytics engine squad efforts (by AMPATH & Google) and simpler approaches (like PIH's PETL)
- TODO: Need a planning/strategy call on way forward for community. Burke will bring to Talk and we'll use some AES call time and/or schedule a separate call to talk through ideas (needs: Eudson, Allan, Mike, Dmitri)
2021-12-06
- Cancelled for GDHF 2021
2021-11
2021-11-29
- Cancelled for OMRS21
2021-11-22
- OCL updates
- Need to address #661 (ability to delete a source even if there are references to it) before we can replace PIH dictionary
- Add support for concept complex handler (#1114)
- Including sources in export (#1115)
- Could use concept_reference_source.unique_id for URI
- For short term, when comparing sources, normalize source names by removing non-alphanumeric chars and lowercasing when comparing names
- Including retire reason in OCL import (#1118)
- Ability to retain/track voided (aka retired) concept names within OCL
- Packaging Updates
2021-11-15
- Jennifer working on unpacking (demystifying) the process of becoming a core contributing organization (e.g., how does one join orgs like PIH, AMPATH, Mekom, etc. in decision-making)
- Connect for Life distribution demonstration - connect-fowww.connect-for-life.orgr-life.org
- "Connect for Life™ is a tailored distribution of OpenMRS. The platform enables increased patient and caregiver engagement through the use of basic mobile phones capabilities (e.g. SMS, IVR, WhatsApp)"
- Built upon RefApp 2.10
- Can send messages to remind patients of visits and to take medications
- Show messages and adherence graph on clinician facing patient dashboard
- Can place calls to patient from dashboard
- Messages sent or to be sent to the patient can be seen within a calendar
- Patients can be messaged via SMS or IVR
- Andy: Can messaging be directed to caregiver? Annik: Yes. Messaging can be customized between patient and/or caregiver.
- Andy: Can interactive responses be returned to the patient's record? Annik: Yes. Surveys can return data into the system.
- Burke: How is messaging being handled under the hood? Answer: Directly using APIs and can configure for various providers.
- Andy: What is being used for data model? Answer: Using OpenMRS for core resources and added custom data model for messaging.
- Burke: Could an existing distribution adopt this functionality? Answer: modules are largely independent. Depends on some things (e.g., phone number within registration)
- Dmitri: How does the UI intertwine with the standard UI? Answer: Using a separate module for CFL UI, but components could be re-used in another distribution.
- Dmitri: Which appointments module is being used? Answer: not using an existing appointment module, but built a different "visit" module to do scheduling. Could potentially leverage visits created from an appointment module.
- Packaging
- Updates? Still conceptual work.
- How do packages declare what is needed?
- Using two concrete examples:
- Mental Health package for ICRC
- OHRI hello world
- Near-term targets
- Skeleton of package
- Manually walking through merging OpenMRS 3.x and a package both using same skeleton
- What are the challenges?
- What are the opportunities for tooling?
- How could it apply to OpenMRS 2.x? Can this be retrofitted to OpenMRS 2.x?X}
2021-11-08
Attendees: Dimitri, Florian, Anjula, Daniel, Heshan, Jayasanka, Jen, JJ, Juliet, Daud, Kumuditha, Mark, Mike, Pasindu, Piumal, Suruchi
- 3.x performance improvements
- Review of proposal from Florian: Performance improvements to app shell and framework Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Priorities
- Review of proposal from Florian: Performance improvements to app shell and framework
- Packaging
- Draft Schema
- Structure
2021-11-01
Recording: https://iu.mediaspace.kaltura.com/media/t/1_4fjqau13
- Packaging
- Last week's decisions
- Combined at build time (not hot-loaded)
- Leverage Maven's conventions for namespacing
- Repository naming convention: openmrs-package-<purpose>
- Using POM or properties file vs including artifacts
- Would like to avoid having to manage/edit POMs
- Consider tooling like Maven Polyglot
- Defer until we decide on structure
- Would like to avoid having to manage/edit POMs
- Distribution vs Package
- Share similar structure
- Distribution includes definitions for specific deployment decisions (e.g., version of OpenMRS platform to deploy)
- Draft Schema
- OHRI Packages Inventory
- Last week's decisions
2021-10
2021-10-25
Attendees: Burke, Michael Seaton, Amos Laboso, Andy, Daniel, Dimitri, Ian, Jen, Juliet, Daud, Mark, Suruchi, Tendo
- Special upcoming community session: OpenMRS Partnership model (Should we host this during a TAC call time?)
- FYI: Community Architect Roles now posted; please add any comments: Architect Roles across OpenMRS
- First pass at a Package: Working session!
- Sample content:
To help bring some real-world context, I’ve set up a list of example package content using the ongoing work from OHRI - see details here.
We’ve now got real examples of real content that would be included in a package, such as:
- Package name
- Concept Metadata
- General Metadata
- Forms
- Frontend Config
- Frontend Modules
- Other OMRS Modules
Other things that I expect will come later are:
- Reports
- Specific Patient State calculations
- Business Rules for Computed Obs
- When will packages be loaded? Do we expect them to be "hot-loaded" into a running system?
- There will be a build step, where package contents and system contents are merged into another.
- Changing functionality at runtime could be re-introduced in the future by performing the build/deploy in the background (e.g., using containers).
- Assuming a package is an archive, how do we namespace contents?
- Packages will need to have a unique ID, so tooling can namespace content. We'll adopt Maven's approach to namespacing (i.e., packages like org.pih.htmlformentry).
- Will need to work out business rules not only to handle dependencies, but also control sequence of files across multiple packages.
- Repository naming convention: openmrs-package-<purpose>
- Do packages need to contain actual artifacts (e.g., modules or other maven artifacts) or just references to them?
- Creating practical examples
- Candidates (we'd like to see 2-3+ early on to test approach)
- Mental Health
- NCD
- OHRI
- PIH has several potential cases
- Candidates (we'd like to see 2-3+ early on to test approach)
- Sample content:
- Conventions for handling issues (will discuss on this week's S&O call)
2021-10-11
- Community Roles
- Grace will soon post about Senior Architects/Lead Dev Community Role Descriptions
- Shared Assets and Fundamental components
- Working on guidelines & processes for how to define and build these to demystify how shared assets are designed/built
- Can share use cases, designs
- Building for & using within multiple implementations helps ensure things are re-usable
- Sometimes things are needed sooner and there isn't time to build them in a fully re-useable way
- First pass at Packaging
- Proposal: working through how OHRI content & functionality could be introduced into OpenMRS 3.0 using packaging approach
- ICRC planning on a mental health package, which could serve as a second proof of concept
- Proof of concept – OHRI programmatic package (COVID, HCT, etc.)
- ESMs
- Concepts
- Forms
- Reports
- Configuration - home screen, dashboard
- Samuel Male will discuss with UCSF team
- We'll continue conversation over Talk/Slack and keep topic on TAC calls to move it forward
2021-10-04
Attendees: Burke, Jen, Amos, Andy, Daniel, Dimitri, Juliet, Mark, Mike, Samuel, Grace P, Suruchi
- Concept Names breaking dbsync
- Potential solution proposed by Mike Seaton would require changing Concept Name from voidable to retireable.
- Dictionary Manager and CIEL do create UUIDs for concept names
- Review & Approval by TAC
- Senior Architects/Lead Dev Community Role Descriptions
- Recognize need for these. Looking to fill these roles (by working with funders).
- Would like TAC's approval of role descriptions within the next week
- Packages prototype plan - where are the soft edges we need to harden
- Get 3.x Foundation
- Work to get SDK to support Iniz (Done)
- Package loading to support to handle backend modules, esms, and other packages (could try with OHRI? Ampath? Demo/Out-of-the-Box Outpatient Package?)
- Put packages inside a new "Packages" folder in folder hierarchy
- How to handle combination of packages?
- Are packages handled/processed independently in a predictable order? Or do we have a build step that tries to merge all settings/content into a single "build"?
- Favoring the latter (merging all packages into a final "build") to be more deterministic/predictable
- Would eliminate support of manually configured systems (e.g., a running system not created through packaging mechanism)
- If it's hard for implementations to convert to packaging conventions for their existing builds, we could create a process to create a package from a running system
- Recognize conflicts
- Merge configurations
- Handling ordering of content
- Are packages handled/processed independently in a predictable order? Or do we have a build step that tries to merge all settings/content into a single "build"?
- Iniz may need to know about alternate
- Create Package
- Consensus on Folder structure (and that we'll build our tools on that)
- Consensus on how Folder gets zipped up → Decision to leverage commodity tools Maven and npm as much as possible? Why create our own bespoke way of packaging things if we already have these tools in use.
- Then: Tool to take Maven XML file and turn into list of versions of properties we have
- e.g.: want certain pt lists. How do you create those lists? → cohorts. How do you represent that in a file? Just the way Iniz does it? (Just use Iniz to build your package)
- Represent these things in the CSV format they're already using
- Exception: Forms →
- Find a Package
- Add a Package to your system
- Where you'd add the config to have it added at build time
- Update a Package
- Can someone start an example template we can review somewhere?
- Get 3.x Foundation
2021-09
2021-09-27
Agenda:
- Supporting organizations in OpenMRS
- Primary goal is to label data being sent to an HIE as coming from a specific organization.
- If we use location hierarchy, we might
- Need to understand use case: are we sending data from OpenMRS as a single organization? Or is there a use case where a single OpenMRS instance would be sending data to an HIE as if from 2+ organizations?
- Supporting Referral Orders
- We reviewed the proposal for modeling new order types within the OpenMRS Platform.
- Mike Seaton pointed out examples like this, where TestOrders are being used (in this example, to add location) and there could be others like this that would need to be refactored.
- We discussed the extremes of lumping & splitting – i.e., from a single Order with the superset of all needed properties for all order types with many properties left blank vs. creating separate classes for every possible order type with the specific properties needed. Both extremes have significant downsides (a single class defers all type-specific behavior to clients and too many order type classes isn't flexible enough when order types – especially the multiple types of lab tests – may be classified differently at different implementations).
- Experience has shown that a handful of classes can cover the needs of order entry (e.g., drugs, tests, referrals, medical equipment, nursing, patient education, diet, activities, precautions, call orders, end of life care), which involves splitting one level deeper than FHIR, but can align with FHIR's approach.
- There was agreement and no dissension on the proposal to add ServiceOrder as an abstract class (extending Order) and making TestOrder and ReferralOrder as extensions of ServiceOrder.
- Burke Mamlin will report this on the Talk topic
2021-09-20
Agenda:
- Supporting Org & multiple Orgs in the backend (like how FHIR doesn't mix location and organization).
- I-TECH would like to have support for Organization in OpenMRS (Mozzy).
- Backend currently has no Org model - whereas FHIR doesn't mix location and organization. (Problem for both Bahmni and UW/ITECH, where this comes up in facility registry workflows.)
- discussion around how we can support the FHIR concept of “organisation” and whether and how we can untangle this from “location”. 2 driving use cases: tagging data as coming from a specific organisation to support integration with a Facility Registry and for referral orders to be able to specify “I referred this patient to XXX clinic”.
2021-09-13
Agenda:
- Dispensing: Service Layer vs new model? (Mark) https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345/14
- See questions on O3 Medication Dispensing page
- Cohort Module Next Steps
- Working on job descriptions for senior architects / lead devs
- OpenMRS Packages
- Will plan to have some discussions about this on upcoming TAC calls
- If there are specific runtime expectations (e.g., settings of global properties), how do we declare these?
- How to deal with conflicting metadata
- PIH is already using Maven to some of these packing steps
- I-TECH would like to have support for Organization in OpenMRS (Mozzy)
2021-09-06
Cancelled due to Labor Day Holiday
2021-08
2021-08-30
Agenda:
- Cohort Module Next Steps
- Persons or Patients for cohorts
- Consider Cohort implementing a "Group" interface
- 99% use case is for Patient, so will stick with Patient
- If Cohorts is only for Patient, then households would require MRN for every household member
- Supporting start & end dates
- Cohort intersections are harder with start & end dates
- Approach for cohort definitions
- Would like to avoid over-designing definition support at this time, but would like to be able to serve up dynamic cohorts from the Cohort Service without hacking with AOP, etc.
- Could use a "status" to determine whether cohort is updating (for long-running calculations)
- Approach for membership roles
- Worth considering for household support, but 99% of use case (head of household) could be done with a membership attribute
- Approach for cohort obs/encounter/visits/programs
- Don't bring this into the platform at this time
- Next Steps: Ian to follow up with proposal
- Persons or Patients for cohorts
- Sourceforge alternatives? https://talk.openmrs.org/t/sourceforge-alternatives/34500
- OpenMRS 3.0 demo & dev environments: Updates? Remaining blockers?
- TODO: Burke will get Ian access to terraform
- Pharmacy-related questions (Mark & David) - conversation on OpenMRS Talk
- Lots of people use Odoo
- PIH using OpenBoxes, would like to build something for the Pharmacist management (would connect to OpenBoxes) unless someone knows of a good open source pharmacy system
- AMPATH is using Maisha Meds
- UCSF is very interested in Pharmacy functionality for OHRI
- Next step: PIH & UCSF connect to review use cases
- Decision: Fine to have Med Dispensing info in EMR, as it is suggested in FHIR. Agreement for new "Medication Dispense" table in OpenMRS backend. https://www.hl7.org/fhir/medicationdispense.html
- Next step: Mark to review FHIR description and come back with core needs identified vs what we already have
- Questions about our Help Desk (Juliet)
- Receiving lots of issues about people creating OpenMRS ID account and not receiving emails
- Next step: Juliet will create an Infra ticket for this This is the ticket for this issue
- People doing marketing or research (can be ignored)
- Receiving lots of issues about people creating OpenMRS ID account and not receiving emails
2021-08-23
- Working on job descriptions for data engineer and frontend architect
- Deploying OpenMRS 3.0 demo
- Ian will work with Burke to get this deployed
- Currently Github Actions are updating import map in Digital Ocean
- Packages next steps
- Get discussion onto Talk
- Build time vs run time? Likely focus on build-time processes for now and anticipate opportunities for run-time deployment in the future (e.g., leveraging Docker)
- Create an inventory of what packages can contain (e.g., 3.x folder structure + manifest)
- Would like to include ETL rules as part?
- Including a "manifest" (try to do via Maven)
- Owner, URL, version
- Version of packaging used
- Get discussion onto Talk
- Cohort module next steps beyond talking - whats the process to get this done? bring to platform team? who is the idea owner? (Ian or Dimitri?) Bett is ready to write the code; we need someone to ensure approach/lay out vision and do PR reviews
- Need to make sure Cohort module can be expressed via REST API
- Burke Mamlin will summarize this discussion into a Google doc and work with Ian Bacher and Bett Kipchumba to bring it to next week's TAC for review
- Confluence/Jira Cloud next steps: SSO is the blocker. Test out leveraging Keycloak; get it working with LDAP?
- Will need to identify someone to spike on this. If not done in 2021, could. use GSoC 2022 project.
- Will need to involve Cintia Del Rio in the migration
2021-08-16: Improving prescribing and dispensing
Attendees: Burke, Mark, David, Daniel, Dimitri, Grace, Isaac, Juliet, Suruchi
- Improving prescribing and dispensing (PIH)
- The ability to dispense meds through UI and for docs to know what meds are available
- Is the underlying approach on how you store immunization data clear? Clearly supported in backend?
- PIH needs a paperless prescribing and dispensing workflow
- Clinicians prescribing meds
- Pharmacy can see prescriptions online
- Ability for pharmacy to make some modifications to an order
- Ability for pharmacy to flag prescriptions as needing attention (e.g., ask provider for clarification)
- Pharmacy to dispense meds
- Clinicians having a sense of inventory at the time of prescription
- Currently using a 2.x version at the facility with the requirement
- Currently OpenMRS has drug table. If the pharmacy doesn't currently provide a med, should it be in the list?
- Burke: I wouldn't use existence of entries in the drug table to manage stock outs; rather, add an attribute to indicate formulary availability to the drug table with something like
drug.out_of_stock
. (not currently in FHIR)
- Burke: I wouldn't use existence of entries in the drug table to manage stock outs; rather, add an attribute to indicate formulary availability to the drug table with something like
- Approach to Pharmacy and Inventory management (embedded vs integrated)
- Ask the community what people are using for pharmacy systems
- Mekom created an ERP system to check inventory/invoice status
- Security
- Isaac Sears has stepped down from overseeing security as he's a "little" distracted by medical school
- OMRS will still need to address 3rd party reports within 90 days (so someone needs to monitor Talk security forum)
- No security mailing list vulnerability reports in multiple months now; seems a result of work addressing vulnerabilities with NC State
- GSOC student experience great; Joshua Nsereko strong & likely to be added to vulnerability response. Sharif Magembe & Ian Bacher have been helping with PRs - good resources.
- Website, product names & logos https://talk.openmrs.org/t/new-website-feedback-on-new-terms-icons-needed/34381
2021-08-09
- Data model implications for Patient Lists / Cohorts and user access to cohorts
- Darius Jazayeriis working on User Groups modeling
- Deploying OpenMRS 3.0 into infrastructure
- Getting very close
- Burke Mamlin will investigate if we have docker images published to Docker Hub or that could be published. Once published
- Packages discussion
- Run time vs Build time
- Do we approach packages as build-time components?
- For orgs/implementations with build pipelines (e.g., PIH, AMPATH, Mekom, etc.), introducing changes at build time is standard practice
- Introducing changes at runtime on production systems can be very risky
- Are there use cases where people depend on introducing new content or modules during runtime?
- Alternatively, we could consider using the existing convention for laying out content & behavior in a folder hierarchy to create a zip file with a manifest that could be "uploaded" into iniz and processed during runtime.
- How would we handle frontend components (esms)
- Do we approach packages as build-time components?
- Run time vs Build time
- Update: OpenMRS Radar has been updated to 2021 Q2
- Next week:
- Improving prescribing and dispensing (PIH)
- The ability to dispense meds through UI and for docs to know what meds are available
- David DeSimone (voluntold by Mark Goodrich) will introduce topic on Talk
- Improving prescribing and dispensing (PIH)
2021-08-02
Call canceled due to lack of quorum
- Data model implications of Patient Lists
2021-07
2021-07-26
Attendees: Juliet, Burke, Ian, Grace, Dmitri
- CI for OpenMRS 3.0
- Latest discussion on Talk
- Cohort Builder Strategy
- Plans for Cohort module
- Creating dynamic lists of patients
- Could use reporting module to generate cohort
- Cohort module could persist cohort definition & handler (e.g., a reporting definition and a class that can turn that definition into a cohort)
- Working on REPORT-873 to allow SQL queries within the reporting engine to perform better
- Packaging Strategy – deferred topic
2021-07-12
Attendees: Isaac, Burke, Ian, Grace, Steven, Mark, Daniel, Suruchi, Andy, Dmitri
- QA Team update on automation
- Use selenium for XSS testing
- Update on conventions for packaging/distribution
- The least expensive way to implement access levels for cohorts:
- Could use cohort attribute to associate with roles as a short-term workaround
- Eventually, would be nice to have something like UserGroup to allow groups of users (potentially independent of their application roles) to access the cohort.
- Need more than boolean (access or not) to support view vs. edit access
2021-07-05
No meeting - vacations
2021-06
2021-06-28
Attendees: Dimitri, Grace, Ian, Mike, Burke, Andy, Cliff, Daniel, Joshua, Juliet, Kaweesi, Suruchi
- Changes to distro POM to make SDK tooling easier (Dimitri, Brandon, Mike) - Conversation on Talk
- Hoping to have a "single source of truth" to represent the needs of a distro (instead maintaining in distro file & POM)
- Do we need to have modules listed in the POM if SDK's maven plugin can manage them?
- Could lose features of maven
- SDK create folder with WAR, omod, OWAs in different directories in target folder.
- PIH has a process to throw those artifacts into a debian package
- SDK could adopt folder structure of iniz
- Packager maven plugin currently create a packaged OpenMRS configuration
- General agreement to align toward using distro.properties as distribution definition with tooling (like SDK) leveraging the same approach, including distro definition and folder layout.
- Currently, SDK does not help with configuration.
- General agreement of separation (loose coupling) of distribution and configuration (i.e., distributions should not be required to have a configuration and a distribution may be deployed with a single configuration or with different configurations)
Summary: eventually, we will want the 3.x distro to be driven by an openmrs-distro.properties file, rather than by its pom.xml + spa-config.json files.
This would require to rely on the SDK, at least to a certain extent.
2021-06-21
Attendees: Dimitri, Juliet, Suruchi, Burke, Jen, Andy, Kaweesi, Daniel, Isaac, Grace
- Reminder
- Lightning Talk on Forms Engines this Friday 25 June at 13:00 UTC
- Changes to distro POM to make SDK tooling easier (Dimitri, Brandon, Mike)
- Defer to call when Mike and/or Brandon can join or take to Talk
- Update on how Workflow State is being handled/planned to be handled in 3.0: Cohort Module
- Program/Workflow - Primarily used for Studies & Treatment Programs
- Cohorts - Patient Lists (used for studies or finding patients with characteristics OR for queueing)
- Derived Concepts (aka Logic, Calculations) - Calculating an "observation" based on existing data
- TODO: Burke will pursue use cases and work on getting design discussion in community (e.g., Talk)
2021-06-13
Attendees: Burke, Grace, Dimitri, Andy, Daniel, Eudson, Ian, Jen, Joshua Nsereko, Juliet, Joseph, Suruchi, Tendo
- Anyone recognize this bug?
- Packages technical modeling ideas
- Package vs Distribution
- Thinking of Packaging similar to Maven's packaging (like a POM file)
- "A package is a bundle of behavior (modules, apps, etc.) and content (concepts, forms, etc.) to solve a particular problem." -Burke
- Distribution declares specific version of core/platform/frontend; whereas, packaging defines requirements but doesn't necessarily declare specific versions.
- Could be done at build time
- Packages technical roadmap
- (DONE) Conceptual idea
- (IN PROGRESS) Specification: Definition of what would be in a package, how it is wrapped
- Directory: Way of finding available packages
- Package Manager Tool: that would "unpack" the package (Unpacker/Explorer/Inspect: Tooling that asks "given this package, what kinds of concepts is it using?")
- Tool expansion: to show dependencies
- Tool expansion: Deal with depenciencies between packages
- Packages technical roadmap
- What still needs to be done to support Iniz Validator (if anything)?
2021-06-07:
Attendees: Grace, Ian, Dimitri, Tendo, Juliet, Daniel, Jen, Settimba
Recording: https://iu.mediaspace.kaltura.com/media/t/1_hi8a7uja
- Confirm Jira workflows update plan https://talk.openmrs.org/t/jira-improvements-update-your-feedback-wanted/29815/15?u=grace
- Recommendation: Retain "claim issue" workflow. OK to proceed.
- Tech Radar:
- Notice: 1 week to make changes then we'll publish that the radar has been updated: https://docs.google.com/spreadsheets/d/1iX_7eUOqHCq2sRrZIDg3HNao_2N0ZaO9VsIdp6d2Rf0/edit#gid=544570639
- Confirmed move of Metadata Mapping form Adopt to Assess
- Architectural Diagram updates
- Reviewed https://docs.google.com/presentation/d/1-jdndM8J9pwQhYVncsRia_pzCGqYYp8fZ5zHUaTbpks/edit#slide=id.p together, will need to come back to how to structure the old orange "Modules" section. Suggestion to remove that for now. "Packages" idea needs more discussion.
- 3.0 Framework & new apps/packages language
2021-05
2021-05-28:
- TRUNK-6006 - burke to follow up
- Time change: Moving to Mondays at 2pm UTC / 10am EDT / 7am PDT / 5pm EAT / 4pm CET / 7:30pm IST, starting June 7.
- How are we using these calls; Goals for TAC for rest of 2021
- Who do we want participating in TAC?
- Representation from Squads and major strategic efforts
- Micro Frontend work
- OpenMRS 3.0 strategy
- Senior design & technical decision makers
- Representation from Squads and major strategic efforts
- What has TAC accomplished by the end of 2021?
- TBD
- How do measure TAC's effectiveness?
- Set goals (at least 2x/year) and reflect on progress (at least 2x/year)
- What is the purpose of TAC?
- Updates? Would prefer to communicate updates in community forum (e.g., Talk/Blog)
- Helping unblock key technical issues (e.g., security issues)
- Brain trust: Access to senior design & technical decision makers
- Make or approve technical/architectural decisions for the community
- Communicate decision/strategy/vision to the community (and stakeholders, like MoH, funders, etc.)
- What we want (to keep)
- The brain trust
- Ability to do deep dives
- Get more folks to join
- What we don't want
- A series of updates
- Being too reactive (keep meetings productive & engaging)
- Who do we want participating in TAC?
- Tech radar
- https://talk.openmrs.org/t/updating-the-openmrs-radar-for-2021/31907
https://talk.openmrs.org/t/take-5-mins-to-help-us-update-our-tech-radar/31657 - Actions:
- Added Ampath Forms and HFE
- Moved TypeScript to Adopt
- Moved Angular to Hold
- https://talk.openmrs.org/t/updating-the-openmrs-radar-for-2021/31907
2021-05-21:
Attendees: Isaac, Ian, Burke, Suruchi, Grace P, Mike, Tendo, Steven W, Juliet
- Please vote on better time: https://talk.openmrs.org/t/lets-find-a-better-tac-call-time/33531
- Notices of interesting work/discussions going on:
- FHIR Module 2 v 1.2.1 - includes support for immunizations & painful bug fixes
- Integrating MF Tooling into OMRS SDK - Brandon working on this and seeking feedback https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/16?u=bistenes
- Storing user-specific settings for OpenMRS 3.0 https://talk.openmrs.org/t/storing-user-specific-settings-for-openmrs-3-0/33519 → Type of thing the Platform Team will help address
- Dev Office Hours on Tuesdays at 3pm EAT
- Progress with program workflow module: Meeting OHRI's needs? Other POC users' needs?
- FHIR review by Burke: Haven't found specific FHIR resources that would be helpful. There are generic resources but nothing ++ specific. Episode of Care. There are "careplans" and "tasks" that track the transitions across states, & plan definition (defines the careplan).
- Follow up with OHRI in subsequent call on progress using existing Program Workflow.
- Suruchi talk: Product Management vs Project Management & key takeaways from the INDUSTRY Virtual Conference for OpenMRS
- Iniz and Liquibase changesets: Process ongoing via PIH of eliminating custom code & standardizing
2021-05-14:
Attendees: Isaac, Burke, Suruchi, Juliet, Grace P, Jen, Joseph Kaweesi, Jude, Daniel, Herbert, Tendo, nyyesigahen
- TODO: F/u with Dimitri on Iniz validation → what are the next steps?
- Demo of Global OpenMRS QA Dashboard - ~10 min
- How to get issues i.d.'d by sonar.openmrs.org more visibility? Should it be a QA Support Team area of oversight/ownership?
- MFE Support in SDK https://talk.openmrs.org/t/integrating-microfrontend-tooling-into-openmrs-sdk/31843/16
2021-05-07: Backend Support for Point of Care Workflows
Recording: https://iu.mediaspace.kaltura.com/media/t/1_n634lqqg
- Grace away Monday/Tuesday next week
- Anyone using old PM Tool? Taking down. Agreed.
- Teaser: Suruchi Product Management talk next week
- QA update next week
- Review Backend Support for Point of Care Workflows / how can we leverage Program Workflow States (~30-40 mins)
- Need someone to own going through requirements and trying out building this into program workflow, and then i.d. where we're finding a blocker
- Fitti to start by asking his team to look at the program workflow module - 2 weeks
- We will reconnect about progress at TAC in 2 weeks.
2021-04
2021-04-29:
Attendees: Ian, Burke, Jen, Isaac, Mike Seaton, Juliet, Grace P, ...
Recording: https://iu.mediaspace.kaltura.com/media/t/1_og7d1xia
- Bintray migration check-in: Largely done. Cut off date tomorrow. Need to update:
- The add-ons server (Ian; in progress)
- Bug in SDK - hyphen marks off name from version; won't support modules with hyphens in name (Ian; in progress)
- Change so SDK doesn't go 1st to Bintray. Prevent confusing error messages in Log file. https://github.com/search?q=org%3Aopenmrs+bintray&type=code
- Travis → Actions:
- Changeover mostly done. Nothing building on TravisCI anymore. Though we got 25k Travis credits. Would run out b/c of the ++ builds we do. Used 300 credits in last mo w/ minimal builds.
- Sanity check of OWAs changed - Could do minor version release for all OWAs to see if everything works as expected. (Ian)
- Will need to monitor Actions; if no PR touched before build it may not run (GH policy due to crypto mining in Actions)
- Core building against 8 versions of JDK - checking that changes don't break in Java 8-15.
- Next week teaser: Backend Changes to support Point of Care Workflows → how to leverage Program Workflow States & existing datamodel; and, make sure we can connect this datamodel to encounters.
- Requirements doc to be shared
- Would be great to have embedded in OMRS 3 w/ flow to transition workflows etc.
- History of modules created where an obs would unlock specific state transitions. But need to address encounter-based workflow needs. Either Patient Program or Patient State
- Looks very similar to workflow PIH needed in Malawi
- Orders Sanity Check: https://issues.openmrs.org/browse/TRUNK-6002 and https://issues.openmrs.org/browse/TRUNK-5992 ; both represent changes to the original order entry API; Mike plans to backport these to 2.3.x
- Looks good
- Platform Team idea
- OHRI bringing 1+ FTE Devs - could get back to ~3 full-time folks helping move platform etc forward
- Platform probably warrants additional care given it's our fundamental resource everywhere
- Platform 2.5 Goals & Resources
- Created https://om.rs/platformboard - Talk & JQL details: https://talk.openmrs.org/t/platform-2-5-release-management-board/33230
- Make Diagnosis immutable for 2.5? https://talk.openmrs.org/t/why-is-diagnosis-not-immutable/33255/5
- Diagnosis and Conditions recorded as obs - when upgraded to 2.2 lost their immutability
- Connects to question of audit log
- Decision: Move forward with audit log. Could have Diagnoses immutable, so long as there's a history of changes. Sweeping change of how voiding works everywhere not in 2.5 scope.
- In 3.0 will be using Form Engine more & more. Accessing data vs viewing data. System Admins will need to see if there's been illegitimate uses.
- Decision: Some audit log improvements could definitely be in 2.5 scope. Created Audit Log epic to track this work:
2021-04-22: Platform 2.5 Planning
Recording: https://iu.mediaspace.kaltura.com/media/t/1_6t365ejn
Attendees: Burke, Tendo, Isaac, Grace, Mark, Mike, Daniel...
Misc Updates:
- Security updates - Isaac following up w/ NCState team on some additional ideas that have been raised. 3 students have applied for the GSOC project!!
- Grace & Mark to follow up on OT Transifex request https://talk.openmrs.org/t/operation-theatre-missing-on-transifex/33119/6
2.5 Platform Release
"Platform" = Core + REST webservices + FHIR. So Platform 2.5 = Core 2.5 + latest REST WS + latest FHIR. Decision: remove OWA + addonManager. Burke to post on Talk about this.
How do we manage what fixes are included?
- Jira decision: Platform should be a high-level concept - having it as a version option is confusing. Remove "Platform 2.5" as a version option?
- Board that shows everything included/desired in 2.5: Instead of having a Platform 2.5 version option, Platform 2.5 board that consolidates anything with the versions for Core 2.5 + latest REST WS + latest FHIR.
- FixVersion 2.5 OR AffectsVersion 2.4
Discussion: Instead of continuing to give people OWA + addonManager included in Platform, should we remove them?
Do we want to continue recommending the addonManager in the Platform release mgmt? Or do we take it out?
- Have been recommending that people use the RefApp instead - then they were happy with this.
- Not aware of anyone using addonManager in production
- Decision: Point them to the RefApp. but include the addonManager (so that non-RA users still have something they can use to manage modules). Not put effort into improving addonManager.
Do we want everyone to continue getting the OWA module?
- We had decided not to promote OWAs. Trying to deprecate them. So why are we giving people an OWA manager out of the box?
- People could still use it, just a bit more work to find and use it.
2021-04-15: Bintray → Artifactory & Travis → GitHub Actions Migrations; How to prevent Platform bugs; RefApp 2.12 scope discussion
Attendees: Ian, Mark, Juliet, Isaac, Burke, Daniel, Grace P, Jen, Sharif, Steven W, Mike, Tendo
Recording: https://iu.mediaspace.kaltura.com/media/t/1_0sn4akep
Jira updates: Spring Graveyard completed; 250 tickets cleaned up. Pattern we're using in Squad calls of using Sprint board.
Bintray migration to Artifactory - Ian - Mostly done, except Add Ons. Now deployed to Artifactory instead; 6 OWAs in RefApp all migrated. Not all underlying jars for OMODs in Bintray exist in Artifactory instance. Might have bare OMODs in Art that could be downloaded and used.
- Still need to migrate Add Ons over to Artifactory - Ian own
- Hard EOL date so bigger priority than Travis
Travis migration - Ian - repos built in last 6 mos covered.
- Reviewing repos built in last 1 yr and migrating those. Ian continuing to do on ad-hoc now. When we need it, we need it, we know how to do it. Key contacts would be: Ian, Burke
- Nice-to-Have Idea: Bot - travis.yaml → go to this wiki page if you want this built
Recent bugs discovered
e.g. links for legacy UI don't work anymore on Platform.
Run platform: legacy UI module links for .form, .list, no longer work at all.
Run setup wizard: displays ugly; not showing images, some buttons not showing up; looks like plain blank page.
Automated UI tests: would have caught both of these. Takes ++ time to find & fix esp. after the fact.
Commit that broke Postgres; commit that broke MySQL.
- CI plan that runs both tests - Postgres & MySQL - could have caught this.
- Do we need to also support MariaDB? So far seems that as long as it works for MySQL, it's ok
- Goal: Daily RefApp build would test against MySQL & Postgres. OMRS Core builds would test against supported DBs on any commit as well.
- (all the tests that run against H2 would switch to run against MySQL/Postgres). No technical blockers.
TODO: Sharif, Daniel, Joseph to follow up on next steps for automating these.
A Key Takeaway: legacyui tests are still valuable because they also expose bugs in the platform
RefApp 2.12 scope proposal
- existing bug fixes - esp. because of # of security issues patched. NC state team wants to publish their findings. Legacy UI module especially key to be updated before they can publish. (Hard publication deadline by end of summer)
- qa tests
- urgent new fixes
- not looking for new feature requests - focus is on cadence, updating module versions. Get latest versions of modules bundled.
- Goal: release within next 1-2 months
- TODO: Post to community requesting release manager; updating on plan
Call for input - ideas to recruit mid-level devs
2021-04-09: XSS patch discussion, Bintray & Travis Migration plan, Showcase debrief
Attendees: Isaac, Ian, Grace P, Daniel...
Regrets: Burke
Recording: https://iu.mediaspace.kaltura.com/media/t/1_gjowtnzi
- Specific XSS patch discussion (5-10mins) (Isaac): Proposal to disallow HTML characters
- Would disallow formatting like <br>...</br>
- Action: Isaac to check on Talk if anyone relying on these. → Decision: To html encode the note. HTML characters can still be entered but won't have a formatting impact - so no HTML injection.
- Logging not happening where it should be
- E.g. deleting a patient
- Plan: add log messages to DAOs → Follow up: conversation ongoing on Talk about Audit module; this solves most of the logging problems NCSU report brought up. Work is going to begin again on that module in May. (Led by Mekom)
- Debrief Community Showcase & 3.0 Feedback Session (All) - what resonated? Surprises? Concerns?
- Recordings are all here: 2021-04 April Mini-Meeting & Spring ShowCase
- Helped communicate where we're going, in a concrete way (e.g. what are MFEs and why are they helpful)
- Updates from Implementers helped confirm we're thinking about right things
- People very afraid of upgrading (to 3.0) - need at least a simple draft migration plan blueprint and a pilot example
- Offline & Mobile CHW use cases quite prominent - we probably need a community design/lightning talk about this - Jen following up
- Migrating off Bintray: Ian/Daniel/Mike working on this
- Trying to get into Maven/artifactory
- Shutting down rights on May 1st; data should be there another 12 mos
- Add on Index updates: Have to change all add ons we indexed
- SDK set up so you don't have to add
- SDK not updated in Maven central for 2 yrs
- Rafal was manually logging into bintray - Ian hoping we can push things from Bamboo to Maven central.
- Still concerned there may be things out there relying on bintray we haven't yet uncovered
- Some OMODs may have been stored on bintray - review JSON file & search "bintray": https://github.com/openmrs/openmrs-contrib-addonindex/blob/master/src/main/resources/add-ons-to-index.json
- Worried some don't actually exist on bintray e.g. commonlabtest
- Group effort + spreadsheet to track what's been checked & changed
- TODO:
- Grace - spreadsheet here, colab notebook here: https://colab.research.google.com/drive/1KIxywIFq4X6qUby8bwph2bhWO60C7GtJ#scrollTo=FI7pj_MaJoVg
- Ian - steps to catch ones that don't actually exist on bintray
- Ian - share on Talk & ask for help
- Migrating off Travis:
- Pretty sure we have everything that was actively running on Travis migrated over. QA issues no longer running on Travis.
- Remaining repos running on Travis are less frequently used - less easy to automate.
- Next Steps: Ian going to go through all these manually
- Daniel's update: Highest priority for now is the automated tests for the platform.
- having all our existing tests running on both MySQL and PostgreSQL
- having tests for the platform setup wizard for both initial installations and upgrades
2021-03
2021-03-26: Iniz/OCL Update, Client vs Server Timezones, 3.0 Framework confirmation
Attendees: Dimitri, Mark, Cliff, Daniel, Grace P, Grace N, Ian, Isaac, Jen, Juliet, Mike S, Moses, Suruchi
Recording: https://iu.mediaspace.kaltura.com/media/t/1_ik3roecf
- Quick check-ins
- Security: NCSU fixes ongoing; HTML fixes in Legacy UI Module - if running into issues w/ error messages let Isaac know.
- Easter Plan? Call next friday or not? TODO: Poll Next Week
- Using Design Sesh Monday to go through remaining Travis projects.
- Virtual Community Meeting happening April 7-8, check it out here
- No more recurring failure issues with CI.
- Update on Iniz/OCL support work (Suruchi)
- OpenConceptLab Loader in progress, some blockers. To post draft PR in Iniz for Iniz team to follow; to write test, starting with test from Metadata Use Case.
- UX implications of storing a preferred time zone as a user property (cfr HTML-755 and related tickets.)
- Because our legacy systems stored time as the server time, just saying "we'll use the client time zone" in 3.0 isn't that simple.
- Need to bring this up with other stakeholders: OHRI, Burke. Do people need to be able to change their time zone?
- Using the client time zone in 3.0 is recommended.
- 3.0 Framework - Confirmed overview of vision & key technical pillars
- No concerns voiced with sample presentation of 3.0 Framework
AES: Focus on FHIR-based reporting - will be good long-term, but may not fit short-term needs of implementations right now. Solution will be needed for those. They can’t wait for state of the art analytics-on-fhir to be ready. Possible ppl start doing other things in the meantime. Pressing reporting needs. Mekom had to use BahmniMart b/c works out of box to get results out of OMRS.
- Capacity building around query-writing w/ new tools
- EIP is where transform would naturally work well b/c extract has already happened - but this workflow isn’t set up in AES; AES using Camel, maybe could/should have been using EIP
Allan mentioned roadmap for non-fhir reporting: What’s the short term solution that could be ready sooner?
Dimitri to join next AES squad call - ideally (1) share market observations and (2) pick up non-fhir reporting
2021-03-19: Plan for Iniz support for OCL, Decision to move from Travis to GitHub Actions
Recording: https://iu.mediaspace.kaltura.com/media/t/1_peabyzal
Attendees: Isaac, Grace, Mike, Tendo, Ian, Burke, Daniel, Jen, Suruchi, Juliet, Mark, Settimba
- Security Update: More PRs coming in from NC State team, Isaac continues to review these. Isaac needs to reduce OMRS duties in August. Jen & Isaac to follow up re. further growing NC State relationship.
- (10 mins) Iniz support for OCL - Overview of technical plan to enable our users to use both Iniz and OCL for OpenMRS
- Use cases:
- Enable Concepts to be loaded into Iniz that are managed in OCLOMRS. Have Iniz use Subscription Module. Looking into loader Iniz using. Goal is to have Iniz understand the OCL .zip file (and the JSON file inside).
- (confirm check-sum is ok) Iniz uses a check-sum to determine whether or not to re-load a file - so whatever we put into Iniz, if it's the same content, then ideally it would have the same check-sum
- Support offline (and reasonable file size). Will support offline loading needs as well / "deploy with USB stick" scenario. (currently 18MB pretty & zipped)
- Example using export of CIEL v2021-01-29 from OCL:
- Raw (one-line) JSON: 270M (17M zipped)
- Pretty format JSON: 325M (18M zipped)
- Example using export of CIEL v2021-01-29 from OCL:
- Support diff check/review of JSON file (user friendly to look at). The OCL .zip may not have been originally designed with that use case in mind. JSON needs to be formatted nicely enough, with predictable order, so that diffs/review would be relatively easy. (e.g. if you produce it 3 times, you get the properties in the same order every time). → May need update to OCL Module to support unzipped or zipped file.
- Pretty-Print Feature request for OCL: a parameter when requesting JSON export to pretty print the content.
- TODO: suruchi dhungana to add issue to OCL GH Issues, and raise in OCL Tuesday call.
- Pretty-Print Feature request for OCL: a parameter when requesting JSON export to pretty print the content.
- Enable Concepts to be loaded into Iniz that are managed in OCLOMRS. Have Iniz use Subscription Module. Looking into loader Iniz using. Goal is to have Iniz understand the OCL .zip file (and the JSON file inside).
- Use #openmrs-initializer channel for updated; can tag Mark Goodrich for support as well
- Use cases:
- (10 mins) CI Plans failing - Process to kill docker containers on build agents (Ian)
- Having to build same build up to 10x/night!! With each push. Productivity killer.
- OCL Builds are big part of the cause - TODO: Burke & Grace to f/u with OCL team; have them set up a separate agent.
- Some discussion re. moving to GitHub Actions. (So far these are free for OSS) Has benefit of not having to maintain infrastructure; and built-in to GitHub.
- Is there a build dashboard product that allows you to point to multiple links (e.g. Bamboo + Travis + GitHub Actions) - reduce duplicated deployment
- Currently have Travis quota - if exceeded, the builds won't build and in PR it says "Pending" (so we moved ++ MFE and modules off of travis)
- Need to understand: What would be the side effects of moving to GitHub Actions? What about Bamboo would we miss?
- Are any modules still using Travis to build? Should move these over to GitHub Actions. Travis.org shutting down in just a few weeks. We already exceeded the restrictions within a week - used 10,030 of 10,000 credits. "Travis is useless to us."
Decision:
Phase 1: Move all our modules/projects (esp. essential ones) using Travis over to GitHub Actions
Possible Phase 2: Move Bamboo builds to GitHub Actions (requires more discussion → Talk)
2021-03-12: Using HTML characters in Test Fields, Technical Overview of New QA Framework
Attendees: Isaac, Cliff, Daniel, Dimitri, Grace P, Ian, Juliet, Kaweesi, Tendo, Mark, Mike, Sharif, Grace N, Jen
Recording: https://iu.mediaspace.kaltura.com/media/t/1_s237111x
- TAC Calls with Timezone - all on call agreed to keeping call at 5pm EAT (will be 7am PST/10am EST) next week
- Security Question by @isears: HTML characters: required when defining relationship types? (security issue if we continue to allow <>)
- https://talk.openmrs.org/t/does-anyone-need-html-characters-in-relationship-types/32584/4
- Possible problems: i18n (what happens with a character like “é”), restrictive for user options (e.g.
Informal “spouse”
orHousehold >5 years
) - Mostly: <>
- Unknown what has already been added in databases around world; would potentially need to reformat reports
- Not convinced risk strong enough
- Applies where we're using JSP/GSP code (legacy ui) - newer technologies apply this already
- Decision: Isaac to go back to team and look at harder/alternative fixes, instead of limiting as described here
- QA Framework technical updates by @k.joseph: Application of Gherkin tests and Cucumber engine, and growing QA Support Team
- Feature Files available here: https://github.com/openmrs/openmrs-contrib-qaframework/tree/master/src/test/resources/features
- https://github.com/openmrs/openmrs-distro-referenceapplication/tree/master/ui-tests
- https://github.com/openmrs/openmrs-contrib-uitestframework
- HOOKs for '@selenium' and '@cypress'
- How to avoid re-writing things that will be the same:
2021-03-05: NigeriaMRS Telecommunications demo, IHE update, Metadata management update
Recording: https://iu.mediaspace.kaltura.com/media/t/1_tth784yw
Attendees: Isaac, Grace P, Settimba, Juliet, Grace N, Mark, Mike S, Jen, Steven Wanyee, Daniel
- Reminder: Vote for a GSOD project. This year is different - we will get dedicated funding to support a Technical Writer on a specific project. Pick one here: https://talk.openmrs.org/t/brainstorming-vote-for-a-project-idea-for-gsod-2021/32289/10?u=grace
- Security update from Isaac:
- We continue to work on the NC State-id'd vulnerabilities. They have provided some undergrad students this semester who will work on patching OMRS SW vulnerabilities as part of their assignments. Meeting with them 30 mins q. Friday. If you see any security-related PRs, let Ian know.
- Nigeria MRS - Isaac
- Workflow for getting a Phone Visit: patients go to a Wix site and submit a form with their information (or they call a clerk and clerk enters it) - that goes into OMRS - custom module shows a list of new patients on the front page, they see the new patients, they call the patient. Clinician has option to follow up w/ pt via text messages (through a new module) - that's Dr. Levine's work. Dev'd custom OMRS modules.
- No video consult
- https://github.com/fortitudoinc/fortitudoinc-infra
- Reach out to Isaac for info of people managing this project today
- IHE update - Ian - IHE Connectathon: Takeaways and roadmap implications (e.g. IPS)
- EU connectathon coming up in May/June
- Update on Metadata management & packaging recommendations: Uzing Iniz, CSVs, +/- OCL for OpenMRS
- Metadata is loaded by Iniz in CSV formats
- See the excellent Iniz documentation for more info: https://github.com/mekomsolutions/openmrs-module-initializer
- CI Breaking frequently this week - raised w/ Cintia, Burke - seems due to Memory leaks. Will this be a consistent scaling problem? If so, we should consider GitHub actions (they use GitHub's infra; can do everything Bamboo is doing; except doesn't give us a unified place to see your build status; Bamboo especially good for managing pipelines - projects running off others)
- Some builds take more memory that others
- Announcements
- OHRI Technical Foundations call on Tuesday next week
- MFE Architecture update session on Monday next week
2021-02
2021-02-25: Platform Release Priorities, Metadata i18n update, & FHIR's International Patient Summary (IPS)
- IHE Connectathon session: Tuesday, March 2 at 10am ET | 7am PT.
- Go to IHE NA Connectathon and click on Register Here or Register Now! • When completing your registration, select the Gold Package • Apply the promo code GlobalGood on the payment page at the end. • Space limited to 150 participants
150 spots available for free for OMRS community
- Go to IHE NA Connectathon and click on Register Here or Register Now! • When completing your registration, select the Gold Package • Apply the promo code GlobalGood on the payment page at the end. • Space limited to 150 participants
- The FHIR IPS (International Patient Summary): Overview, maturity level in the context of implementing the SHR specification of OpenHIE
- Designed especially for "unplanned, cross border care". Very untested at this point - most production use we've heard of is it being used to exchange some information across medical practices in Argentina. Decent structure to start from for an SHR.
- IPS Implementation Guide: https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Composition-uv-ips.html
- Very simple to support. Was very straightforward to set up basic level for IHE connectathon: Ensured there were intl SNOMED codes in the data and then these were readable.
- Doesn't get you what you might need in more regulated environment
- US, Canada, AUS, UK all have own version of FHIR-based continuity of care documents. None based on IPS but IPS informed by some of them.
- IPS could be helping form a nucleus of, what information should be shared in an Intl context?
- Comparison to US CDI (Core Data Initiative): Some useful patterns but would get very hard to use directly in an Intl context. e.g. way CDI profiles patient: needs to support races and ethnicities, but definition of what qualifies for these refers to specific US regulations of what the US gov defines as race, which may not be helpful internationally.
- IPA Initiative: More a CDA, made more internationally available.
- If a specification is needed right away by an implementer, the CDA is the low-hanging fruit. But IPS is likely to replace as next version.
- Most people are using FHIR to support national systems, rather than for international data exchange.
- IPS may eventually be superior to the CDA because the underlying structure is just via resources - so if your system supports FHIR, you can import them as if they were native data.
- Work ITECH has done in FHIR squad lately is already pulling down support for parts of IPS.
- Concern: Cross-border care is a much rarer use case than
- Update on metadata i18n: we seem unblocked: https://talk.openmrs.org/t/i18n-support-for-all-classes-extending-baseopenmrsmetadata/26218/24
- TODO: Just need to make sure in MFEs code is using the display property of the resource (not the Name property) to the user → TICKET TO CHECK
- TODO: Confirm that FHIR API is returning the display property (not the Name)
- Dimitri & Mike working on update to Iniz: https://github.com/mekomsolutions/openmrs-module-initializer/issues/95 This will create way to define metadata and the different locales you want to support. They experimented with this and changing the locale in Iniz just worked at changing the messages.
- Addresses Mekom's biggest concerns about OMRS i18n.
- UI Framework is driving
- Though - it would be nice to switch btwn locales without having to change the backend. Display string could show all the locales supported; so you could pick this and see everything that's supported - toggling btwn Eng/Fr/etc happens in a snap. Could be helpful for offline.
- RTL & date formats
- Platform Roadmap priorities - MetroRetro board: https://metroretro.io/board/LBQDUT9RE2V1
- OCL v Iniz: Iniz will support OCL config file
Platform Release Priorities: Ideas Deep dive.
2021-02-19: Implementing Patient Flags/Alerts, and key updates from the FHIR, Analytics, and MFE Squads
Recording: https://iu.mediaspace.kaltura.com/media/t/1_pihdlh25
Attendees: Burke, Daniel, Dimitri, Grace, Ian, Isaac, Jen, Mark, Mike, Sharif, Tendo
Updates
- Security: Weekly Sync with NC State students to support their issue work
- Jira proposal: In 1 week, we’ll change all the Jira projects using the RefApp workflow to use the TRUNK workflow. https://talk.openmrs.org/t/jira-improvement-plan-part-2-trunk-workflow-replace-confusing-ra-workflow-to-use-the-trunk-workflow/32282
- (5 mins) (Grace, Dimitri, Mark, Mike) Update on OCL Subscription Module v Iniz conversations this week
- Iniz would have 2 different formats; could have it refer to Subscription Module (by using OCL Subscription Module API; would be aware of module and depend on it) (low-hanging fruit for Iniz)
- JSON Output needs to be readable & consistent (predictable sort order) - so it’s easy to diff
To Validate w/ Subscription Module:
- Not too slow for 10,000’s concepts (TODO: Grace check)
- Consistently exports it the same way every time so you can handle diff
- Ability to sync or export multiple collections - not handled well w/ Subscriptions atm (UI designed for 1 link) - add to roadmap
DONE: Mike to look at Subscription Module code. Looked good; trying to do all the right things. Using multi-threading to try and import the concepts and mappings as quickly as possible (even moreso than some of our other, single-thread tech.) Seems well thought through. Does rely on ordering of the JSON structure & how it’s formatted.
- (5 mins) (Grace, JJ, Dimitri) MFE Squad Update - Carbon progress and April pilot plan
- Decided to move ahead with Carbon 5 mo ago. Accelerated designs and generally positive team feedback. Tablet designs done; wrapping up desktop behavior now.
- Need component library for devs to grab from (copy and paste code).
- Working towards April pilot of new UX in HIV Outpatient clinic at AMPATH in ~April
- Experimenting with AMRS Form Builder
- Still plan to support HFE; may be through iframes; not a top priority at the moment. Angular App - showing Angular App running in a REACT App! (Win w/ MFE framework that that's possible.)
- Decided to move ahead with Carbon 5 mo ago. Accelerated designs and generally positive team feedback. Tablet designs done; wrapping up desktop behavior now.
- (10 mins) (Burke) Analytics Engine Squad Update - pilot launch plan & FHIR schema decision
- AE Squad Prepping to launch ETL pipeline for performant analytics at AMPATH
- ITECH already using Analytics Engine pipeline to generate the patient data to send via FHIR to SHR in Haiti; using batch pipeline
- Based on decision to use FHIR schema (using as basic representation for clinical data from OMRS; stored as parquet files b/c they're a columnar format that can be efficiently queried; Google research has shown this approach can significantly improve the speed of queries. Can write queries in python or SQL.)
- Looking for additional implementers and pilot sites - want input so we make a solution that works for multiple implementers
- TODO: Grace f/u w/ Bashir and Allan re what someone can run on their machine to check it out
- New Data Analytics person joining PIH
- (5 mins) Ian & Grace: Overview of FHIR squad shared priorities. Confirm FHIR being used as main modality.
- Main momentum around integrating OMRS into an HIE ecosystem - esp. for CR/MPI and SHR (implementers bringing requirements). MPI/SHR work spearheaded by ITECH; squad trying to extend it for others to use.
- Patient flags has lot of overlap w/ Analytics Engine b/c "this VL is dangerously high, consider moving to new ART"
- module: Patient Flags Module does this. But performance very poor: Every flag is a SQL query, so when viewing the pt chart, every SQL query has to be run to generate the flags.
- FHIR aspect similar to pt list discussion: Bett has added support for patient lists in FHIR. Next is to set up system-generate lists e.g. "patients who are due for an appointment today" "patients who may be LTFU"
Big Topics
- Patient flags discussion: https://talk.openmrs.org/t/openmrs-3-0-patient-level-notifications-vs-patient-flags/32204
- FHIR flag description: https://www.hl7.org/fhir/flag.html
- Need to identify ideal FHIR resource for "Sticky Notes" (suggestion: keep as observation, at least as first step)
- Ideally: System would look for flags in FHIR for that patient
- Alerts are something we'll likely be looking into in the UX workplan in the MFE squad
Posting coming from Burke about 2021 Technical Vision - decision to go towards MFE approach; reporting via Analytics Engine, etc
2021-02-12:
Attendees: Isaac Sears, Grace P, Dimitri R, Juliet, Ian, Burke, Mike Seaton, Jen, Mark G, Daniel, Andy K, Settimba Lamech Nalumoso, Cliff
First half: Announcements & unblock specific questions. Second half: Key technical updates you should know happening around the squads.
- Announcements:
- (2 mins) Fellowships Spots open - spread the word & let us know if you want to help review applicants. https://talk.openmrs.org/t/openmrs-mentor-and-fellow-opportunities/31966
- (5 mins) (Burke) Brief introduction to OHRI project
- "OpenMRS HIV Reference Implementation". UCSF leading dev. Timeline: Proof of concept by Sept. Overall a multi-year project.
- (2 mins) OpenHIE Experiment: Update on IHE Connectathon HIE use case happening in 3 weeks (Ian & Piotr)
- Cloud Hosted OMRS paired to HAPI FHIR server (using FHIR IPS content)
- Sending messages via OpenHIM
- OpenCR on proxy HAPI FHIR server
- SHR stand-in on HAPI FHIR server as standalone
- Using the iSantePlus distribution of OMRS
- Cloud Hosted OMRS paired to HAPI FHIR server (using FHIR IPS content)
- (10 mins) (Dimitri and Andy) Discussion: adding a ‘conceptnames’ domain to Iniz
- Iniz 2.0 release coming very soon (so this will need to be part of a another future release)
- Mekom plans to combine OCL with Iniz; meeting happening Monday w/ Ellen/Suruchi/Michael/Grace to review this
- Overlap with OCL Subscription Module? Whether it makes sense to have Iniz Module and Subscription Module. MDS has been hassle.
- (5 mins) (Dimitri) Backend Forms Validation
- not talking about frontend form logic here, but backend integrity validation.
- (10 mins) (Grace) Overview of the OCL Client
- What it is and how it's useful to rapidly manage concepts
- Reviewing Subscription Module overlap w/ Initializer
2021-02-05: SSO with OpenMRS
https://iu.mediaspace.kaltura.com/media/t/1_hawh0zzk
Attendees: Burke, Dimitri, Ian, Daniel, Grace Nakiguli, Grace Potma, Jennifer, Juliet, Isaac Sears, Mike Seaton, Tendo Martyn, Moses Mutesa
Recording: ___
- SSO with OpenMRS: Demo of SSO working with the RefApp and Google OAuth (Mekom)
- via Google API. Code here: https://github.com/openmrs/openmrs-module-oauth2login
Burke Mamlin does a little dance because TRUNK-381 (created in 2010) for alternate authentication scheme support has finally been implemented... only 11 years later!
DHIS2 about to support this workflow as well due to ICRC requirements
- Iniz use cases: Mekom, PIH, MSF, Regenstrief
- Deep dive on issue with Iniz: Making ConceptName a first class domain object
- Dimitri R described an issue they were having with concept names, since iniz expect each row to be an "object" that it can clear & reset according the CSV and concept names are referenced directly (from obs), preventing them from being arbitrarily deleted & recreated
- Deferred topics
- Quick review of OCL for OpenMRS: Different than OCL
- Setting the stage for a deep dive: Proper support for i18n of metadata
2021-01
2021-01-29: Modeling Patient Lists with FHIR groups, Tech Radar changes, and final GSOC project list review
Recording: https://iu.mediaspace.kaltura.com/media/1_1uvnkxbx
Attendees: Ian, Dimitri, Isaac, Burke, Daniel, Jen, Bett Kipchumba, Steven, Grace Bish, Mike Seaton, Tendo Martyn
Update on Timezone convention:
Dimitri working on wiki page for timezone conventions; PR to fix a couple places where new conventions aren't followed yet (e.g. in HFE). Hoping we could have one piece of code, a utility class in core, that we can point to as the string convention to follow. Currently staged in an HFE pr.
20 mins - Decision Needed to Unblock Patient Lists: Using cohorts to model FHIR groups (Ampath is blocked on implementing; proposal and previous discussion here)
- Proposal: Represent patient version of group using cohort for that - PR pending to do exactly that. But we don't currently have FHIR expression for characteristic (needed in order to express groups by characteristics of patients, e.g. male >50yrs).
- What we don't want: to end up with groups in FHIR, cohorts in core, and some definition of patient lists all living somewhere else.
- Decision: Expanding cohorts in core to meet the needs of FHIR = better.
- When: Platform 2.5 release too far away; and anyway, lift of doing a platform upgrade out of scope for immediacy of Ampath's needs. Can we support this update to core via backporting to 2.0 or 2.1? Start with support in 2.5, and plan a structure for 2.1 that will upgrade into 2.5
- Next Steps: Ian and Bett to follow up on next steps; Bett to proceed with work as planned/described in order to support Ampath's urgent need of patient lists; Ian to provide model guidance as-needed.
20 mins - Tech Radar Feedback from this survey: https://forms.gle/F5NHH8Q7F9TYEy2i9
- Angular → Assess? → Burke to bring to community on Talk
- TypeScript: What do people find difficult about it specifically?
- Kotlin: Being used in Zambia ++ → Steve to f/u re. how much this is being used
Changes made today:
- Carbon → Adopt
- Bootstrap → Hold. since there are no plans to adopt it further, and we don't want to cause confusion while we are putting more emphasis on Carbon
- Reference Application as Framework → as Foundation
Additions to consider:
- Tomcat or other J2EE container(s).
- Standard Deployment conventions: Artifact Packages (how to make this more clear - no clear convention right now; might use docker, ansible, etc; something we could point people to)
20 mins - Review GSOC Project list
- General agreement voiced for GSOC '21 projects that have been proposed
2021-01-22
Attendees: Dimitri, Burke, Mark, Cliff, Daniel, Isaac Sears, Jennifer, Juliet, Mozzy, Sharif
Reminder: Next week = Radar update discussion. Complete prep work here (5 mins): https://forms.gle/F5NHH8Q7F9TYEy2i9
- TODO: Grace f/u with Isaac re GSOC project
- TODO: Grace f/u with Ian about Micro Frontend UI for FHIR metadata CRUD operations
Big
- Prioritize 2021 Roadmap items https://metroretro.io/board/LBQDUT9RE2V1
- GSOC projects - any final discussion needed (time sensitive) Summer Of Code 2021
Focused (will probably impact roadmap discussion somewhat)
- Nailing down timezone conventions: Need unique way across OMRS; ongoing blocker for Mekom. Talk convo & Slack convo heading in the following direction; let's confirm:
- How does the server send dates to the client? Answer: Only UTC dates from backend (then frontend can handle changing to timezone of user). Define what's stored on the server so the REST layer can do a conversion as needed
- But: 1.x versions may not be able to handle this conversion.
- Ideally should always return timestamps with a timezone (right now people have to assume in some places that it's UTC). ICRC having to set up servers in UTC in order to be sure. But can create situation where DB timezone is different than client server (because these will be locally hosted)! ("Local time" is generally equivalent to "where our server is")
- Challenge: Approach doesn't handle sites with DST
- Challenge: Encounter dates are handled just as dates without a time stamp. Assumes T = 00:00:00 → Making this change could affect this and cause people problems
- How does the client send dates to the server? Answer: ISO 8601 dates.
- The client should display local dates and times to users. (so it should do this with the dates it receives from the server, UTC → client timezone).
- Agreement: Defining at a server level what data are stored, what's used for timezone data, leveraging that info at the REST layer to always send time in UTC from REST calls (but explicitly include timezone so it's UTC not assumed to be UTC).
- Todo: Explicit Documentation of "This is How to Implement Timezones". Clear place in server to say "here's what the timestamp is in this server" so REST calls can use that to convert time stamps as needed to the location of the request.
- How does the server send dates to the client? Answer: Only UTC dates from backend (then frontend can handle changing to timezone of user). Define what's stored on the server so the REST layer can do a conversion as needed
2021-01-15
Recording: https://iu.mediaspace.kaltura.com/media/1_b08tbxxl
- Platform Roadmap: Ideas Deep dive.
- MetroRetro board: https://metroretro.io/board/LBQDUT9RE2V1
- Survey results/ Radar thoughts: https://forms.gle/F5NHH8Q7F9TYEy2i9
- GSOC Projects: Deeper dive into short-list of proposed GSOC Projects
- Current list: Summer Of Code 2021
2021-01-08: Tech Radar intro review; Approaches to Managing Config; More detail on new Config Validator
Recording: https://iu.mediaspace.kaltura.com/media/1_v39b9j72
Attendees: Burke, Isaac Sears, Daniel, Dimitri, Ian, Ines Fernandes, Jennifer, JJ, Luis, Mike, Pedro, Reagan, Tomas Oliveira, Sharif, Stephen Musoke, Sharif, Tendo, Moses
Quick Updates
- Security
- Isaac working on Wiki clarity (Security pages) especially about process & how we handle vulnerabilities based on feedback from OMRS20. Big NC State report handed over has 100's of points Isaac is working through with them - several of the NC State team members have been actively making PRs to fix issues! High-severity issues have so far not been reproduceable. Platform-level and anonymous attacks are what we're looking out for especially.
- Q1 Goal: Focus on vulnerabilities outlined in NC State report. Isaac organizing into Jira issues, then will be looking for help w/ patches. XSS bugs may be GSOC appropriate.
- OpenMRS Radar change plan update
- OCL for OpenMRS: details of Q1 goals (i.e. the plan to make this thing useful for more implementers!)
- Analytics Engine Squad: details of Q1 goals – (1) getting engine running in parallel at AMPATH, (2) getting a 2nd implementation to try/test engine.
- PIH & Mekom interested to look at it.
- Caution that "analytics" phrasing can cause confusion about whether it competes specifically with DHIS2. Be careful with messaging: "Nice bridge to DHIS2".
- Perhaps adding "getting data to DHIS2" as a parallel goal with indicator production would help underscore how the analytics engine is meant to expose data to tools like DHIS2 and not to replace or compete with tools like DHIS2
Meaty Topics
- Platform Roadmap - Daniel
- Priorities to use to help direct volunteers to right priorities - What should we be setting as the platform targets for the year?
- Platform 2.5.0 Release Board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=238&view=planning.nodetail&issueLimit=100
- Ideas
- Proper support for i18n of metadata - at the data model & API ideally
- Support for growing the ability to search? Patients and concepts indexed with Lucene via Hibernate. No HTTP rights for Lucene.
- Deep dive into Initializer Validator & how Mekom is using MariaDB
- ICRC to start running that Validator
- PRs pending last year are now done Check it out: Initializer Validator ready for testing ahead of 2.1.0 release https://talk.openmrs.org/t/initializer-validator-ready-for-testing-ahead-of-2-1-0-release/31556
- Validating HFE Forms' Metadata
- Mike pushed ability to ship as part of the config → means ability to validate forms as part of configuration. Validating the metadata, specifically the concepts used by the form.
- Load concepts
- Run the tool
- Shows whether the concepts referenced by this form exist in the config - Checks that "yes, this concept exists in the DB".
- More discussion needed to allow flexibility needed for use cases like UgandaEMR: https://talk.openmrs.org/t/initializer-validator-ready-for-testing-ahead-of-2-1-0-release/31556/8
- Want to get rid of data exchange and metadata management module. Need all config resources to somehow be in the resources of module artifacts.
- The new OHRI/PEPFAR HIV RefApp will also need this. If we could use one config tool for both the old and the new - ideal! And would drive adoption across other implementers too.
- Issue is packaging for deployment.
- Mike Seaton to follow up with Stephen Senkomago Musoke with comparable PIH examples
- Mike pushed ability to ship as part of the config → means ability to validate forms as part of configuration. Validating the metadata, specifically the concepts used by the form.
- @ifernandes has been asking about our Transifex process(es): https://openmrs.slack.com/archives/C03U2P841/p1610095458266800?thread_ts=1607598106.246700&cid=C03U2P841,
- What job pushes to Transifex? How to solve i18n messages, from coreapps, that were never pushed to Transifex? Next link shows the messages files where new labels were added, however they are not on Transifex.https://github.com/openmrs/openmrs-module-coreapps/pull/358/files
- Mike Seaton to follow up - possible there's a misconfig or access issues
- GSOC Projects: Plan to identify projects (proposals due to Google by end of Jan)
- Burke proposed having a "theme" for GSoC 2021, where most/all projects would be part of a larger goal of replace our legacy administration functions with a micro frontend-based UI (scope limited to filling the current REST API gaps and carbonizing - not feature improvements at this time)
- XSS bugs may be GSOC appropriate