2009-05-07 Developers Conference Call

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
3 min read

<html><head><title></title></head><body>h1. Date

7 May 2009

In Attendance

  • Ben Wolfe
  • Burke Mamlin
  • Justin Miranda
  • Hamish Fraser
  • Mike Seaton
  • Darius Jazayeri

Agenda

  • Hamish wants to talk about meeting in Boston
  • Darius will bring up some thoughts on why encounter types should be concepts
  • Automatic liquibase updates need to go away. I have 5+ development environments and I always end up forgetting to switch the database in my runtime properties before deploying a version of trunk. This ends up killing my 1.4 database that took hours to import. I am proposing a flag set in runtime properties that disables the automatic update of the database. I will add a ticket and patch this week.
  • Sync updates
  • 1.5 alpha

Minutes

  • Meeting in Boston
    • There are many groups wanting to talk about their implementations or potential implementations in developing countries
    • 60+ people
    • Can break in 3-4 group easily and talk about technical issues, implementation issues, US issues, etc
    • How its been used dev countries + US, an overview of openmrs, highlight current implementations, where we are, how its designed/structured, a panel/broad discussion at end of morning for Q+A. an afternoon of breaking out. Have the people coming to this drive what they want to talk about.
    • TODO: Hamish to draft a schedule
  • Liquibase
    • Add liquibase to modules instead of sqldiff. <strike>TODO: Mike to create ticket</strike> - #1474
    • If liquibase updates haven't been applied at startup, a "maintenance page is shown". Have a user authenticate via jdbc as a System Developer and take them to a "perform these updates" page.
  • Darius's points on encounter types should be concepts
    • Malawi asked for concepts for all enc types because they wanted to store in the obs table an answer like: "type of scheduled return visit"
    • Either obs.value_coded should store things other than concepts or enc types become concepts
    • Burke: We should figure out what enc types are before we do anything.
    • Burke: In Kenya we use enc types as just "Adult Return", Adult Initial, Peds Return, etc
    • Darius: We use the same in Rwanda
    • Darius: We should talk about how encounter should be used.
      • How to model an entire visit?
        • See registration clerk
        • Vitals taken by a nurse
        • See doctor
        • See pharm to get meds
      • How to form a group of encounters?
    • Darius: We have concepts for each of our locations in lieu of value_location
    • Burke: We need value_coded to link to any kind of code set, not just concept.
    • Burke: Direct quote: You can turn anything into a thing.
    • Burke: Look to hl7. PV1.patient_class (recurring patient, n/a, unknown, emergency, in/out patient, preadmin) chap 3 table0004
      • Not helpful.
    • We need to model 1-n forms per encounter. But its a matza ball B
      • TODO: Burke create ticket for it. → #1476
  • Annotations for spring controllers are in trunk
    • Pro: You no longer have to have just one formbackingobject
    • Con: mappings are split up into different controllers instead of one xml file
    • Pro: Quick and easy to create new mappings/pages/controllers
  • Convenience methods on services
    • Darius wants PersonService.addPreferredName(Person person, String prefix, String given, String, middle, String family, String familyName2, String suffix)
    • Burke likes it
    • Ben does not
    • TODO ?
    • Investigate @Service Spring annotations
    • Investigate whether we can get rid of Service interfaces and just use classes
  • Crud for domain objects
    • We don't need Service.saveEncounterType/ServiceImpl.saveEncounterType/DAO.saveEncounterType/DAOImpl.saveEncounterType
    • We could reduce all of these down to Service.saveEncounterType/ServiceImpl.saveEncounterType/DAO.saveEncounterType/DAOImpl.saveEncounterType
  • Persistence of different objects
    • TODO: Ben look into possible solution
  • Transactions
    • Darius: transactions should be around the whole http request, not just each API save
    • TODO: Darius to look into possible solution
  • Sync updates
    • uuids has been merged to trunk
  • 1.5 alpha released
    • We need to do some testing
    • TODO: Darius to post the PIH's script for checking on things
  • Nightly trunk (bleeding edge) builds need to be put up somewhere: http://nightly.openmrs.org ?

    </body></html>