5 November 2009
- Paul Biondich
- Michael Downey
- Max Headroom
- Darius Jazayeri
- Burke Mamlin
- Saeed Mehrabi
- Win Ribeka
- Mike Seaton
- Ben Wolfe
- Justin Miranda
- Zeshan Rajput
- Is Hibernate's ehcache disabled?
- Are we not using concept set derived?
- Module resources and moduleIds with dots in them
- catch-up about wednesday morning's design call
- should retiredReason and voidReason be required
- Discretely define what determines that something becomes part of core OpenMRS.
- Puntable Agenda Refactor the program and workflow to person from patient.
- Puntable Agenda Add an obs.voided_obs column http://dev.openmrs.org/ticket/1458
- Puntable Agenda Logic caching
- Paul: Rwanda meeting went well. They are now working on requirements gathering, setting up interoperability profiles, and working on the infrastructure. Created a WHO "proclamation" to address the minimal policy commitments from a country toward eHealth.
- Darius give some background about the design review call yesterday.
- Burke: the call should be assessing a design, not designing itself. So, someone should already have a design prior to the call.
- Justin: there were some weird issues with inheritance
Concept Set Derived
- Michael: Concept Set vs Concept Set Derived
- Darius: There's no API to get concept set derived
- Expunge ConceptSet and keep the operation behind the scene.
- Darius already have the code.
retiredReason and voidReason
- Is it necessary to make required?
- Some user just put random value in to bypass the checking
- API is the convention. Putting the required in the field is way to encourage people to follow the convention. Even though it is hackable (user can put anything in the field), but the API try to show the correct path (i.e. best practice).
- We don't have awesome javadocs in our code.
- Keep the restriction on real data not on metadata.
- Vote: Patient, Obs and Encounter will still have the voidReason field mandatory
- Will wait for Tammy.
- Darius: Need refactoring on the program workflow. Outcome of the program for example
- Punted to AMIA meeting.
- TODO: Need to see Tammy and Vibha's documentation on the work they have done so far
What In The Core
- Module that essentially core openmrs but happen to be in module because it needs to evolve faster than the core.
- Or module that will be bundled in the openmrs release (bundled modules)
- Module that will be maintained and supported by the OpenMRS core developer --> bundled modules.
- Modules need to go through QA / QC, upgrade also must go through the core dev.